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I. INTRODUCTION 

A. BACKGROUND DISCUSSION 

In 1981, The U.S. Coast Guard created a new Office of 
Command, Control and Communication. This Office has set 
forth the infor nation architecture concept for the Coast 
Guard, which is committed to investing in the architecture 
cf the future today so that the Coast Guard may become an 
"information corporation" of the 19 90's. The Commandant of 
the Coast Guard has identified three critical success 
factors (CSF) : intelligent terminals, data base management 

systems, and t e lecommun ica tions networks. The intelligent 
terminals (standard terminals) are already being acquired 
and configured for applications. Data base management tech- 
nology is to be employed in major operational and 
administrative systems under development, as well as in the 
future Coast Guard District minicomputer procurement. This 
thesis will address the Coast Guard's second CSF - data base 
management systems - looking at how the Coast Guard should 
implement database technology in a distributed mode, given 
the present heterogeneous hardware/software systems and 
planned system acquisitions. 

B. RESEARCH OBJECTIVES 

The primary objective of this thesis will be to provide 
the Coast Guard with a strategic plan for implementing data 
base technology given the present configuration of the Ccast 
Guard and the status of systems available today. A secon- 
dary objective would be to present what future trends in 
data base technology are foreseen and the situation of 
present data base systems in general. 
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C. THESIS SCOPE, LIMITATIONS AND ASSUMPTIONS 



The main thrust cf this thesis will be an examination of 
the various Data Base Management System (DBMS) architectures 
available as well as an examination of + he Coast Guard's 
requirements for data base technology. Future trends in 
DBMS technology will be examined, realizing that the systems 
acquired today will be affected by the technological 
advances which occur in the near future. The researchers 
did net confine the scope of the thesis to any one specific 
organizational element of the Coast Guard, but rather 
attempted tc consider the requirements of the organization 
as a whole. The reader is assumed x o have at least a 
cursory knowledge of computer systems nomenclature. (Note: 
The authors will not attempt to use a single spelling of 
either "data base" or "database" but will use both inter- 
changeably since both spellings are used throughout current 
literature) . 

D. METHCDOLOGY 

The methodology employed in this research effort was 
primarily an observational type approach coupled with an 
extensive literature review of current books, periodicals, 
articles and journals, as well as Coast Guard directives, 
plans, and policy guidance. These literature reviews were 
augmented by interviews with appropriate personnel as neces- 
sary. These research techniques were appropriate because 
they furnished Coast Guard requirements while identifying 
the available technologies and future trends. 
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E. ORGANIZATION OF THE THESIS 



The following is a breakdown of the various chapters 
included in this thesis: 

Chapter II - This chapter provides the reader with the 
current framework or situation which the researchers 
faced ir. conducting their research. 

Chapter III - This chapter discusses some organizational 
implications which may affect the Coast Guard's Command, 
Control and Communications program goals in general, and 
the data base coals in particular. 

Chapter IV - This chapter discusses the future tech- 
nology developments in data base management systems and 
how these developments will affect the currently avai- 
lable alternatives. 



Chapter V - This chapter provides a detailed description 
of three currently available architectures ar.d discusses 
the strengths and weaknesses of each. 



Chapter VI - 
researchers 
i implement ing 



This chapter provides a 
believe the Coast Guard 
database technology. 



strategy which the 
should employ in 



Chapter VII 
res earchers' 



- This chapter provides a summary 
conclusions and recommendations. 



of the 
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II. RESEARCH FRAMEWORK 



A. GENERAL 

The purpose of this chapter is to give the reader an 
understanding of the framework which the researchers 
addressed in formulating this thesis. The authors will give 
a brief overview of the missions assigned J -o the U.S. Coast 
Guard anc then look at how 4 -he Coast Guard is organized in 
order to accomplish these missions. The researchers will 
then look a~ the plans, policies and resources dedicated to 
the Command, Control and Communications program of the Coast 
Guard in supporting their mission objectives. A brief look 
at the current technology framework is included to describe 
the environment of the information systems industry facing 
the Coast Guard today. 

1 • Coa st Gu erd M iss ions 

The United Spates Coast Guard was created in 1790 by 
an Act of Congress which was initiated by the Secretary of 
the Treasury, Alexander Hamilton. The primary purpose of 
the organization was initially to collect tariffs for the 
country to offset the debt from the Revolutionary War. This 
organization was first called the Revenue Cutter Service and 
had an initial complement of 10 cutters with U0 total offi- 
cers. In 1915 the Life Saving Service was combined with the 
Revenue Cutter Service -o form the U.S. Coast Guard. The 
Lighthouse Service was amalgamated in 1939. At present the 

Coast Guard is tasked with performing the following 

mis sicns : 

SEARCH AND RESCUE (S AR) : Locating and assisting persons and 

property in distress on -he high seas and U.S. 
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jurisdictional waters. Charged by the National SAR Plan 
with total respcnsibilry for SAR in the North Pacific and 
most cf the North Atlantic. 

ENFORCEMENT OF LAWS AND TREATIES: Place territorial and 

adjacent waters under surveillance to deter illegal activi- 
ties, acquire relevant data, and promote safety of life and 
pro perty . 

AIDS TO NAVIGATION: Ooerat e and maintain a complex network 

of navigational signals (e. g. buoys, lights, radio beacons) 
covering all U. S . jurisdictional waters, and radionavigation 
signal systems (IORAN and OMEGA) meeting the requirements of 
the Department of Defense and the civil community. 

ICE BREAKING: Clear passage through frozen waterways for 

ship movements and conduct scientific research in ice 
covered waters. 



MARINE ENVIRONMENTAL PROTECTION: Perform surveillance of 

maritime areas fcr evidence of discharged oil, other hazar- 
dous substances and ocean dumping violations. Prevent 
unauthorized discharging and enforce applicable laws and 
treaties. Ensure necessary containment and removal of 
s pi 11s. 

MILITARY READINESS: Maintain an effective force of 

personnel, facilities and equipment in a state of readiness 
fcr war cr peacetime emergency. 



RECREATIONAL BOATING SAFETY: Conduct safety 

cially in areas of high beating density, 
officials and the Coast Guard Auxiliary 
increase recreational boating safety, and 
safety through public contact. 



patrols, espe- 
instruct state 
in methods to 
promote boating 
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COM MEECIAL VESSEL SAFETY: Develop safety standards and 

enforce them through vessel and equipment inspection, vessel 
documentation , investigation of accidents and violations, 
and licensing of seamen. 

PORT SAFETY AND SECURITY: Enforce laws and safety regula- 

tions. Facilitate traffic movement. Investigate accidents 
and violations. Monitor leading operations and movement of 
vessels carrying hazardous cargo [Ref. 1], 

The Coast Guard is the smallest of the U.S. Armed 
Services and is unique in that if performs these various 
peacetime missions as opposed to the other Armed Forces 
which really only perform wartime related functions. Having 
a multitude of missions has created some debate as to which 
department the Coast Guard should belong. Originally, the 
Ccast Guard was part of the Department of Treasury, but in 
1967 the Coast Guard was placed under the newly created 
Department of Transportation. Some observers have stated 
that the Coast Guard should be part of the Treasury 
Department while others feel it. belongs with the Commerce 
Department. Another view points out that since the Coast 
Guard is ultimately an Armed Service, it should be part of 
the Depar-menf of Defense. Table I relates the various 
missions which •'the Coast Guard performs to the Federal 
Department tc which that function would be connected 
[Ref. 2]. Reference 2 points out that there are various 
reasons for not putting the Coast Guard in either the 
Department of Defense, Commerce or Treasury and recommends 
that the Ccast Guard remain a part of the Department of 
Transportation, with which the researchers concur. But it 
is observed thaf there will continue to be speculation of 
relocating the Ccast Guard as long as if remains a multi- 
missicn organization. In recent years this fact, along with 
being a relatively small organization, has contributed 
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T ABLE I 

Coast Guard Missions by Logical Department 






MISSION 

Armed Force/M ilt ary Readiness 
Maritime Law Enforcement / 

Navigation 

-fisheries, sanctuaries, mammals 
-Navigation laws, aids to navigation 
-Navigation faciltation 



logical DEPARTMENT 
Defense 
Commerce or 

Transport ation 



Maritime Law Enforcement Justice 

-Drug Interdiction 
-Immigration Laws 

Maritime Law Enforcement Treasury 

-Customs Laws 

Marine Safety Functions Transportation 

-Search and Rescue 



-Aids to Navigation 
-Commercial vess el, boat ing 
and port safety 

Marine Environmental Protection EPA 
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toward giving the Ccast Guard somewhat of a visibility 
problem. The end result of this visibility problem is that 
if has been difficult for the Coast Guard to get adequate 
funding and resources in order to properly carry out the 
missions wi*h which they are assigned. In 1980, in combina- 
tion with the office of Management and Budget and the Office 
of the Secretary of Transportation the Coast Guard carried 
cut a sophist ica +ed zero-based personnel study. This study 
considered the [fissions currently assigned to the Coast 
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Guard and the program standards developed for current levels 
of operations. The study found that to continue the current 
level of operations without deterioration of plant and 
equipment, the Coast Guard would need between 9,000 and 
15,000 more personnel than they currently have. The average 
age of Coast Guard ships is 27 years and there is approxi- 
mately a $2-3 billion backlog in capital investment to its 
aging shore facilities [Ref. 3], 

The bottom line with regard to this discussion is 
that the Coast Guard is a severely resource constrained 
organization (as all organizations would probably admit, but 
the researchers believe that the Coast Guard is especially 
so) . Let us then proceed to look at how the Coast Guard is 
organized to carry out its missions and then look into how 
the Coast Guard bandies its information resources. 



E. COAST GUARD ORGANIZATION 
1 . General 

The Coast Guard is an organization with approxi- 
mately 39,000 military personel and 6,000 civilian 
employees. Coast Guard Headquarters is located in 

Washington, D. C . and is divided up into staff elements 
responsible for the various operational or support programs 
the Coast Guard carries cut in support of its assigned 
missions. (The Search and Rescue program is an example of 
an operational program.) These staff elements are often 
referred to as program managers and they set the policies 
and objectives for their respective programs according to 
the guidance set forth by the Commandant of the Coast Guard, 
a 4-star flag rank. 

The next organizational level in the Coast Guard is 
broken down into two Area Offices - the Atlantic and 
Pacific, located in New York and San Francisco respectively. 
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TABLE II 

Coast Guard Districts 



ATLANTIC APE A 




PACIFIC AREA 


1st: 


Boston, Ka. 




11th: Long Beach, Ca. 


2nd: 


St. Louis, Ho. 




12th: San Francisco, Ca. 


3r d: 


New York , Ny . 




13th: Seattle, Wa. 


5th: 


Portsmouth, Va. 




14th: Honolulu, Ha. 


7th: 


Miami, Fl. 




17th: Juneau, Al. 


8th: 


New Orleans, La. 






9th: 

L 


Cleveland, Oh. 




- .... - - _ _ 1 


Each Area is then subdiv 


ide d 


into District regions. Table 


II show 


s the breakdown 


of D 


istricts with the location of 



each cf the District headquarters. Each District is then 
subdivided into Groups, Stations, and Captain of the Port 
zones depending on the needs of each particular District. 
The various afloat resources are distributed among the 
Districts with Coast Guard aircraft being operated out of 26 
different air stations. The District Commanders are respon- 
sible for all operational ac-ivities within their geographic 
boundaries. Each Area office provides administrative and 
operational support and guidance when more than one District 
is involved in a common mission. Since almost every Coast 
Guard unit is considered mu ltiraissior.ed , management of oper- 
ational, logistic and informational support can be a 
difficult task. 

At this point, the researchers will briefly describe 
how the management cf information resources fits into the 
Coast Guard organizational picture. Prior to 1981, 
management cf information resources was essentiallly split 
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between 'three Headquarters’ program offices - OTM : 
telecommunications division, SEE: electronics engineering 

division, and FIS: information systems division. OTM was 

responsible for the general operation and technical perfor- 
mance of the Coast Guard communications system. OTM also 
played a substantial role as technical advisor and ’market- 
ing' agent for the Office of Operations in translating 
mission needs in + o system requirements for EEE to actually 
acquire. EEE was responsible for all electronics systems in 
use operationally with specific responsibility for 
computer/information systems when used in conjunction with 
these operational systems. FIS was responsible for almost 
all of the Coast Guard's computer systems and some special 
data communications systems. FIS was created in the 1950’s 
as primarily a croup of experts running and building appli- 
cations on cne central computer. 

On 17 March 1S81, the Commandant announced his deci- 
sion to form a new Office of Command, Control and 
Communication (G-T) which was a direct result of the 
Decision Support Systems Study Group (DSSSG) report. The 
most significant point raised in this report was that full 
integration of ^he three divisions (OTM, SEE, FIS) was 
necessary in order to maximize the human and financial 
resources available to meet the unprecented demands for 
information technology. 

The Office cf G-T has been subdivided into several 
divisions to carry cut the functions previously performed by 
OTM, EEE and FIS; in addition, it has added a new staff 
component, the Plans and Policy Division (G-TPP) . This 
division's functions include: (1) managing and performing 

planning functions fcr the allocation of Coast Guard-wide 
resources to the G-T program, (2) Information Resources 
Management (IRM) and (3) Data Resources Management. 
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A broad definition for Information Resources 
Management (ISM) is the effective and efficient utilization 
and control of the resources (i.e. hardware, software and 
data) necessary tc support the information processing 
requirements of an organization. Information is now seen as 
a primary resource of an organization in that it allows the 
members of the organization to answer questions and solve 
problems, there ty achieving organizational goals. As a 
primary resource, information needs to be effectively 
managed just as any o^her resource (i.e. manpower or 
capital) is managed by an organization. 

As part of the 1981 formation of the Office of 
Command, Control and Communication, seven 5-year goals were 
established: 

(1) Support Goal - Providing the support and mainte- 
nance of installed hardware/software systems occupies 
cne-half of the Office of G-T. The goal is to continue and 
reduce the cost of this support program management with 
continual sensitivity to the difference between actions 
necessary to maintain system performance and chose chat 
improve it. The latter are also the responsibiltiy of the 
support forces, but improvements must compete with other 
worthwhile projects for resources. The SUPPORT and 
OPPORTUNITY goals are complementary; either one, if carried 
to excess, can render the other unachievable. 

(2) Acquisition Goal - The Office of G-T is the 
designated support manager for acquiring major electronic/ 
computational systems, and the goal is to develop an 
adaptive organization to carry out this mission with project 
management techniques. ’Acquisition’ is the entire func- 
tion, from concept through deployment and acceptance by the 
operating and support managers. ’Major' is a case-by-case 
decision reflecting funds, quantity, time, failure-risk, 
etc. A large-dcllar replacement acquisition may well be a 
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support/maintena nee action, while a small ne w-technology 
project could require a 'major acquisition' project. 

(3) Opportunity Gcal - The Office of G-T, in 

pursuing the above two goals, will have many opportunities 
(e. g. , in allocation decisions, degree of budget emphasis, 
use of small discretionary resources, etc.) to tackle other 
goals of opportunity. For example, within the support/ 
maintenance environment, a familiar target of opportunity is 
to seek improved performance in the course of a 

maintenance- just ified action. This goal, coupled with the 
SUPPORT goal, is to aggressively pursue the use of informa- 
tion technology -Throughout the Coast Guard wirh + hese 
'opportunity' resources. This service-wide use of informa- 
tion technology is to be in accord with the Commandant's 
long range goal-seeking efficiency through automation and 
effectiveness through decision support. 

(4) Operation Goal - The Office of G-T is charged 

with the operation of four facilities to directly support 

Coast Guard Headquarters: Flag Plot, COMMCSN, National 

Response Center, and Terminal Center. The goal is to 
increase the efficiency of this support, particularly 
through use of information technology, withour an increase 
in resources. 

(5) Maritime Communication Policy Goal - The Office 
of G-T performs a unique function in government forums 
(domestic and international) in fields within this umbrella 
subject, such as spectrum management and radio distress 
policy/technology. The goal is to draw upon the increased 
technical and senior management resources of the new Office 
to increase Coast Guard effectiveness in this subject 
without new resources. 

(6) Human Resources Goal - There are two dimensions 
to the qoal for human resources - the general program 
management of the officer and enlisted specialty groups 
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under + he cognizance of the Office of G-T, and of rhe 
personnel assigned to the Office staff at Coast Guard 
Headquarters. In the former, the goal is efficient use of 
these people in meeting most of the above goals. This 

requires considerable integration of previously separate 
specialties, development of new career patterns and 
retraining. In the case of Coast Guard Headguarters staff - 
particularly civilian staff - the goal is one of opportunity 
for personal growth and development along with the new 
Office. Such development would be through training and new 
positions in the new subjects being undertaken. 

(7) Information Resources Management - An accesssory 
function in the su pport/raaintenance area for information 
systems is 'data base administration'. This forms a core in 
the broader IRK subject which includes manual (paper) 
systems and other topics such as office automation, elec- 
tronic mail, and teleconferencing. Future assignment of 
these responsibilities to the Office of G-T is intended; the 
goal is mature development of the initial data base concepts 
and inclusion within the next several years of the manual 
sysrems management into a true IRM role for the Office. 

The researchers consider the IRM goal to be the most 
significant and revolutionary for the Coast Guard of the 
seven goals established by the Office of G-T. The ether 
goals support already well established programs in the Coast 
Guard, whereas IRM is essentially a new one, and one which 
the researchers believe is essential if the 'information 
corporation of the 1990's* concept is to be achieved. 
Database technology is one aspect of IRM in that it supports 
the IRM goal. Therefore, recognizing the importance of IRM 
for the Coast Guard, the authors’ will discuss IRM with 
regard to the Coast Guard's present situation, planned 
growth, and how database technology fits into the Coast 
Guard's IRM goal. 
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The following paragraphs show a breakdown of some of 
the factors which the researchers feel will be affecting the 
Coast Guard in the management of information resources and 
in the attainment of the above stated goals. Assumptions 
and constraints ccncerni ng these resources are also 
included. 

2. Cperatio ral Resources 

Table III shews the breakdown of the current level 
of major Coast Guard resources. Drastic changes in the 
level of these resources is not expected in the next five 
years especially in view of the budget situation presently 



TABLE III 

Coast Guard Operational Resources 

CUTTERS: 250 

AIRCRAFT: 173 

BOATS: 20 00 
SHORE FACILITIES: 700 



facing the Coast Guard. The Coast Guard is acquiring 11 new 
270 foot Medium Endurance Cutters which will improve the 
average age of the fleet somewhat when they replace some of 
the most aged vessels. With regard to operating resources, 
the Coast Guard will continue to maintain equipment in the 
most effective manner and will seek -o acquire the most 
technologically optimal systems available. Improved manage- 
ment of information resources is of high importance in- 
allowing the Coast Guard to keep its operational resources 
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in the highest level of readiness possible. Discussion of 
information resources will be included below. 

3 . Eudqet 

The current level of the budget for the Coast Guard 
is approximately $2 billion annually. Of this amount, a 

portion is spent in supporting the Coast Guard information 
resource requirements (either directly or indirectly) . 
References 4 and 5, outline the budget and resource alloca- 
tion process to be followed with regard to the Coast Guard's 
Command, Control and Communications Support program. These 
policies are consistent with the Coast Guard's Planning, 
Programming and Eudgeting System (PPBS) . The summation of 
these policies is as follows: 

(a) Major information systems will be capitalized 

through Acquisition, Construction and Improvement (ACSI) 
budgeting. Acgusition will be done by Coast Guard 

Headquarters tc program manager specifications. ACSI 
billets will be required, and the program manager will 
need a degree cf experise in stating requirements. 

(b) Small to medium-scale systems can be supported by 
Resource Change Proposals (RCP) , by a program's internal 
funds, or by competition for the Headquarters Office of 
G-T's small, in-house resources. 

(c) Small to medium-scale systems would normally be 

procured by the Office cf G-T, although the program 

manager could do this himself following applicable 
standards . 

(d) Installed "institutional" or Coast Guard-wide offi- 
cial systems will be under the Office of G-T's 
configuration and standards management. 
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(e) Operating expense fcllow-on resources for mainte- 
nance of informational management systems must be 
identified for the users fcr adequate provisioning. 

At any rate, although the Coast Guard's expenditure 
for information resources will be increased in view of the 
previously discussed reorganization, the overall Coast Guard 
budget is not expected to increase in any significant 
amount, and may actually decrease when the effect of infla- 
tion is taken into account. The researchers therefore feel 
that the Coast Guard MOST make prudent decisions about the 
hardware and software it acquires today to improve its 
information resource management, in order than in does not 
alienate many of its members from future use of this equip- 
ment through bac experiences with the systems which are 
purchased now. 

4 . Fer sonn a 1 



As mentioned earlier, the Coast Guard is presently 
made up of about 39,000 military and 6,000 civilian 
employees. Appendix A shows the latest, personnel resources 
presently assigned tc the G -T program. The most important 
note to make concerning Coast Guard personnel in the infor- 
mation resource arena is that there is currently a critical 
shortage of qualified people. FY80 estimates identified a 
shortfall of approximately 90 professionals merely to main- 
tain existing systems and complete development of already 
initiated systems. The 1981 reorganization only served to 
identify more shortfalls by opening up more billets in the 
information resource management program. Training and 
education are obvious parts of the solution to this problem, 
but meeting the Coast Guard's needs will require a strategic 
approach to the overall management and use of personnel. 
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5. A§sum£t i cns and Constraints 



The users of the Command, Control and Communication 
(G-T) prcaram are the entire Coast Guard plus parts of other 
goverment agencies and the maritime community. This thesis 
assumes no basic changes in the traditional organization or 
mission tasking. 



There will be little or no expansion in the total 
resources available to the G-T program, although it will 
continue to compete vigorously in the budget process. 

The core of the G-T program strategy will be one of 
centrally providing concept design, standards, acquisition 
and control of major systems or application of major 
resources throughout the entire Coast Guard. 

There is a family of externally imposed requirements 
which impact on ■’■he manner of execution of the G-T program. 
These are, generally, the original Brooks Act which empowers 
GSA with sole ADP equipment procurement authority; the 
myriad cf computer-related Federal procurement and Federal 
Property Management Regulations which implement the Brooks 
act; ether Federal Regulations and various interagency 
agreements. These factors will be discussed in greater 
detail as aDpropiiate [Ref. 4], 



6 . ADP B gu i pme nt 



a. Existing Tools and Facilities 



The following paragraphs contain a brief list of 
present facilities which in some manner support Coast Guard 
information processing. In the next section, the 

researchers will discuss the future information architecture 
developments being planned for the Coast Guard. The authors 
discuss the present resources in order to show that these 
resources consist of outdated equipment put together in 
disjoint systems, which appear to have evolved in response 
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tc narrowly scoped requirements without consideration 
consolidating the facilities which perform similar functions 
into more effective, general purpose systems. The 
researchers want to convey the image that Coasr Guard infor- 
mation systems are currently behind the times, and can be 
better managed, but that positive steps are being taken in 
that Coast Guard is realizing its problems and is taking 
action tc correct the situation. 

Communications Stations and Padio Stations 
These facilities provide personnel resources and equipment 
for data transfer shcre-to- shore and ship- to-shore . 

Electronics Engineering Center and Electronics 
Engineering Laboratory, Station Alexandria - these provide 
electronics engineering personnel expertise for field 
maintenance management, field testing and special systems 
dev elopment . 

Command Centers (Communications Centers and 
Operations Centers) - these provide the nuclei for contin- 
uing command and control of all Coast Guard operations; 
provide a continuity of management of all activities durina 
ncn-wcrking hours; provide for the management of all elec- 
tronic information flows into and out of District offices; 
and they will become increasingly dependent upon information 
technology. 

Leased lines and GTE TELENET Packet Switching 
Network - Leased lines are procured from the telephone 
company and provide the equivalent of a pair of wires from 
point to point - these are now used extensively in landline 
communications and in the District data network; GTE TELENET 
is a shared, computerized communica tions system which the 
Coast Guard has selected as a critical augmenting resource 
for servicewide communications needs. 
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AUTOEIN - currently AUTODIN is the backbone of 
CoD message ana stcre-and- f crward data communications, and 
provides the bulk of inter -district message communications 
for the Ccast Guard; DoD does not charge for this service; 
DoD is currently designing a packet switching replacement, 
similar to GTE TELENET network; FAA is designing a similar 
one, called NADIN II, which the Office of the Secretary of 
Transporattion (CST) is considering for a Department - wide 
net work. 

Model 28 Teletype mechanical communications 
terminals - these terminals are physically and technologi- 
cally very old and are becoming extremely difficult to 
maintain in operation; -hey have very low capacity (75 bits 
per second, about 100 words per minute) and possess no capa- 
bility for intelligent message handling. 

VHF/EM and HF Radio Communications Systems 
installed radio networks provide the bulk of operational 
command and control for mob ile -units, and coordination with 
civilian marine traffic. 

District Northern Telecom DATA 100 Remote Job 
Entry Terminals - these are high-speed, intelligent termi- 
nals which can be programmed in a short time to communicate 
over leased or dial-up lines with a variety of computer 
equipment in several protoc els; they can also be programmed 
to execute simple processing locally in a language called 
RPG ; these currently support the bulk of district data 
processing needs with the Transportation Computer Center 
(TCC) and local processing. 

Word Processing Systems - in use at various 
locations in the Coast Guard serving primarily word 
processing and some list. processing functions; some have 
higher processing capability; many can be used in a communi- 
cations environment, and can be utilized as terminals; 
wherever appropriate and economical, these systems will 
remain in place. 
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Mini and microcomputers - various models exist 
throughout the Coast Guard supporting important functions 
for local needs; as long as these needs are being satisfied 
in an economic manner, these systems will remain ir. place. 

Operations Computer Center (OCC) and Computer 
Centers at Aircraft Repair S Supply Center (ARSC) , Academy, 
Coast Guard Yard, and Supply Center at Brooklyn, NY - These 
major processina centers will provide special processing 
needs to programs or facilities. 

DOT and Other Governmental Computer Service 
Centers (i.e. TCC, Transportation System Center, FAA 
Aeronautical Center, National Institut.es of Health, Walter 
Reed Army Hospital, Navy Fleet Numerical Oceanography 
Center) - these systems provide general-purpose computing 
resources to the Coast Guard, on a r ei mhurseable basis, 
shared by other agencies. 

Commercial Timesharing - Competitive single-user 
contracts, GS A Multiple- award schedule contracts, and 
DOT-wide multi-user contracts under negotiation; the advan- 
tages of this type of service are first, higher levels of 
analytical assistance and second, usually more reliable 

on-line, interactive service; this better service carries a 
higher cost. 

For the interested reader. Reference 4 contains 
an inventory of the software systems cuurently in use 
throughout the Coast Guard. 

b. Projected Coast Guard Information Resources 

Arch itecture 

The purpose of this section is to give the 
reader an understanding of how the Coast Guard’s existing 
resources and faciities will be expanded, reconfigured and 
utilized in the next 5-10 years. References 4 and 6 provide 
a more detailed description of this topic. 
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The words information and data have various 
meanings and sometimes the words are used interchangeably. 
The Coast Guard has decided to refer to data as static enti- 
ties with assigned definitions. Information is the enhanced 
meaning of value associated with these data when they are 
somehow processed cr utilized by human or machine inteli- 
gence. As an introduction to the Coast Guard's future 
information resource (IR) architecture, it is useful to 
think about information in three global ways in which the 
organization uses it - namely hierarchical, transactional 
and local information. 

Figure 2.1 shows hierarchical information 
flowing from ~he smallest unit, to the ■ t cp of -he Coast 
Guard, and ultimately beyond to both Congressional and 
Executive recipients. Hierarchical information supports the 
management control and strategic control functions of the 
organization. 

Figure 2.2 snows transactional information, 
based upon data groupings that flow intact from point-to- 
point in the organization and usually cause or support rapid 
act iv ity . 

Local information is anything and everything 
that any individual cr organizational element chooses to 
utilize when it is not institutionally required to do so. 
Strategic design of the information architecture recognizes 
the use and need cf local information for maximum user 
benefit. The architecture must provide some reasonable 
facility for each level of the organization to meet its 
local information needs. 

Figure 2.3 shows the merger of traditional 
record communications and future data communications. The 
various networks are simply treated as resources to move 
data, and it becomes a network management task to insure 
that operational transactions are handled with adequate 
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Figure 2. 1 Hierarchical Information. 

priority. By implementing most data communications as an 
enhanced version of record communications, upward-compatible 
and graduated growth is achieved, as well as the loosesr 
possible dependence between physically separate information 
resource elements. 

An important feature of the information 
resources architecture is the new Coast Guard Standard 
Terminal. This piece of equipment has been chosen to be the 
primary 'standardized 1 computer hardware device in the Coast 
Guard for the 1580's. It can be viewed as a relatively 
inexpensive device with three essential features: 
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Figure 2.2 Transactional Information. 

(a) Communication - the terminals can communicate 
ever all of the channels planned for Coast Guard use, 
with software and hardware supplied by the vendor. 
They can also be clustered among themselves for 
sharing of processors and data, with the wire inter- 
connection being the communication channel. 

(b) Human Interface - With its CF.T screen, software 
and keyboard it can easily be used by all levels of 
Coast Guard personnel. The special function keys and 
electronic generation cf f iil-in-the-blank forms make 
it capable of being viewed as only marginally 
different from paper and pencil, functioning as the 
source of data for all three types of information. 
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Figure 2.3 0. S . Coast Guard Planned Information Architectur 
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(c) Prccess/St crage - The medium sized microprocessor 
(Intel 8086) present in each terminal gives then the 
ability to meet nearly all local information needs 
for the 1980's. In addition, standing alone it can 
perform many cf the formal transactional and hier- 
archical processing functions [Ref. 4 ]. 

Three categories cf communications networks will 
be used by the Coast Guard in the 1980-1990 time frame. 
These are an outgrowth of the Coast Guard's command hier- 
archy and the record message store and forward communication 
mode. These three categories of networks are national, 
regional and local networks as shown schematically in Figure 
2.4. 

NATIONAL NETWOEK - The National Network is a generic 
term which encompasses those means of interconnecting 
major Coast Guard national switching nodes. (The major 
switching nodes are presently Districts, communications 
ar.d radio stations. Any possible combination of uncon- 
nected networks may be chosen in the future but today’s 
Coast Guard 'National Network' consists of 
SARIANT/SARPAC (Coast Guard search and rescue systems), 
AUTCEIN, Secure Command and Control Network, (all three 
interfaced by manual tern-tape operation), TELENET, and 
the leased Information Network. 

REGIONAL NETWORK - the regional network will provide 
connection and information exchange between the regional 
nodes and local nodes (end user terminals or local area 
networks) . This is anaiageus to the District or Group 
Teletype net. (Beth National and Regional Networks may 
ultimately end up using the same network techr.olgy as 
ARPANET.) 

LOCAL NETWORK - The local network will provide connec- 
tion and information distribution (exchange) between the 
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Figure 2.4 Coast Guard NETWORKS. 

local network, or local area network (LAN) as they are 
popularly called and connect users intra-building, 
intra- facility or intra- industrial park. Examples of 
present LAN's ere a shared logic word processing system 
connecting all offices in a District Office, a loop of 
Model 28 Teletypes controlled by an HP9825 or on-base 
administrative teletype systems. In the future these 
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LAN’s will be much more capable of handling large 
volumes of information and a heterogeneous mix of users 
(such as Wang Net) [Ref. 6], 

The Coast Guard's last main feature of the 
information resource architecture is that of data resource 
management. This concept deals with the fact that data is 
an important resource of an organization and that the 
management (the collection, storing and processing) of the 
data is a crucial determinant for the success of any planned 
information resource architecture of that organization. 

The focus of this thesis is concentrated in 
looking at how the Coast Guard addresses the problem of 
information resource management via DBMS technology. More 
will be discussed concerning planned growth for Coast Guard 
information systems in Chapter VI. 

C. TECHNOLOGY FRAMEWORK 

The researchers will now discuss how the current 
'state-of-the-art' has evolved in computer or information 
systems environment specifically with regard to data 
resource management. 

When computers were first introduced in the 1950 's hard- 
ware cost was the most significant factor. The computers 
were relatively slow (especially when compared with today) 
and designed primarily for the solution of sophisticated 
mathematical number crunching problems. As the speed of 
computers improved, the ability of computers to process a 
lapge amount of repetitive data was recognized and computers 
began to be utilized increasingly for ' management- related ' 
processing (i.e. payrolls, personnel, inventories, etc.). 
But still throughout the 1960's, the computer was viewed as 
a large, expensive machine kept in a central location and 
operated by specially trained, dedicated personnel. 
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Efficiency cf the machine was stressed due to its high cost, 
and if it just so happened that the reports a manager was 
getting were not responsive to his needs, then getting a new 
report created was net an easy task. This was because one 
had to get the analysts and programmers together from the 
data processing department, tell them what was necessary, 
and have them write a new program to do it. If it didn't 
turn out the correct way, a person might nor go back to 
change it because of all the trouble to do so. Data in this 
type of situation was probably centrally located, but as 
discussed, getting tc the data was often not very easy. 

With the revolution of integrated circuits and silicon 
chips, the speed of computers increased greatly while the 
price cf computers decreased even greater. Mini and then 
microcomputers were introduced with recognition that not all 
situations require a large mainframe and often it is advan- 
tageous to have several smaller computers instead of one 
great big one. 'Power to the people' has been used to 
describe this philosophy of providing a small, low-priced 
computer directly tc a user in order to be more responsive 
to his particular needs. As data sharing needs grow, these 
independent smaller computers can be interconnected to form 
networks or distributed systems. 'EFFECTIVENESS' (utilizing 
the computer *0 achieve optimal assistance to users in 
meeting their needs) rather than ’EFFICIENCY' (achieving 
optimal utilization cf the computer) becomes the important 
factor with regard to this type of computer architecture. 

But, as is the case in a changing world, when you solve 
old problems, new ones often appear. As the use of 
computers grew, and more people used them, more programmers 
appeared and often different sections or departments in the 
same organization developed their own programs. This was in 
part because the organization wanted to make the computer 
more responsive and give the end users better control, but 
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problems with data redundancy and consistency appeared. 
Each department began maintaining their own set of aa-.a, and 
often this data was repeated in several departments. 

This led to the development of data base management 
systems in crder to allow sharing of data, to control data 
integrity, to allow greater data independence, and to 
improve data recoverability [Ref. 7], These data base 
management systems are sophisticated software products which 
provide for effective management of data resources, and when 
combined wi^h a special query language can be utilized by a 
non -specialist user to quickly access the data base in a 
responsive manner. West of these DBMSs are designed for a 
single computer. The Coast Guard has decided on a policy of 
distribution of computer resources in which the information 
resources (hardware, software and data) are placed in the 
hands of the commander who exercises responsibity and 
control over the forces they support. Therefore the Coast- 
Guard faces a problem of managing data resources given a 
distribution of those resources. 
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III. ORGANIZATION A L IMPLICATIONS 



A. GENERAL 

In this chapter, the researchers would like to take a 
look at the overall direction the Coast Guard is headed with 
respect to information systems and database technology, and 
then relate this direction with what is happening in the 
information systems industry at this time. The authors will 
discuss seme organizational impacts which may be expected as 
a result of the actions taken by the Command, Control, and 
Communication program of the Coast Guard. Finally, the 
researchers will provide some recommendations for planning 
for and dealing with these impacts in order to minimize any 
negative effects. 

B. DIRECTION CO ?ST GUARD IS HEADED 

The direction the Coast Guard appears to be taking in 
the information resource management (IRM) area seems + o be 
one of greatly increasing the importance cf and improving 
IRM throughout the organization. This is evidenced by the 
reorganization and consolidation of the organizational 
elements involved in this program, and the commitment of 
spending more dollars on upgrading IRM capabiliies. The 
major goals of the Command, Control and Communications 
program were outlined in Chapter II of this thesis, and the 
Coast Guard appears to be pursuing these goals in a system- 
atic manner with controlled growth, coordinated acquisition 
policies, and expansion of education and training opportuni- 
ties for personnel in this area. The researchers feel very 
strongly that the overall direction of improving the effec- 
tiveness of IRM by the Coast Guard is highly valuable. 
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somewhar overdue , and will put the organization in a better 
position to overall manage its total resources. The use of 
data base technology is just one avenue for increasing the 
effectiveness of an organization's IE M. What are ether 
related technologies, and how does ■‘•he Coast Guard stand 
with respect to these concepts? 

Reference 9 discusses some of the new technologies in 
the IRM field which are available at this rime. These 
include : 

1 • Tex* Ha n c li ng 

Most organizations have realized the importance of 
having mest printed text in machine readable form in order 
to speed up the production, update and correction of printed 
documents. Often referred to as word processing systems, 
these type systeus can be obtained as a microprocessor dedi- 
cated to this task or as a feature of a general purpose 
computer system. The Coast Guard has implemented word 
processing systems in varying degrees throughout rhe organi- 
zation. These range from the simple, stand-alone dedicated 
systems to sophisticated, i nter connect ed, multiuser systems. 
The Office of G-T has decided that where cost-beneficial, 
these systems can be continued. The standard terminal is an 
example of a general purpose system which can be used for 
word processing. 

Cne common extension of word processors is the 
ability to electronically send documents between processors 
in different locations in lieu of having to manually trans- 
port the hardcopy. Therefore, it is necessary for 
communication standards to be established in order that the 
machines can communicate with one another over the estab- 
lished protocols. Standards for interfacing dedicated word 
processors with larger general purpose computer systems 
should also be required. The Coast Guard has recognized the 
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importance of such standards and has promulgated the proto- 
cols to be utilized by the affected equipment in Reference 

a. 

2 • Mes sagi n c 

This concept is related to the feature discussed in 
word processors on electronically sending documents, but 
should be considered as a more general feature than iust 
sending documents. Messaging conveys the idea of using the 
information system as a means to send communication between 
individuals without having person-to-person or telephone 
contact. This concept is often referred to as electronic 
mail. An example of messaging would be a system which 
allows text messages to be sent from terminal to terminal 
enabling a person to use the terminal directly for reviewing 
incoming messages thereby cutting down on actual paperwork 
and speedina up the communication in the process (i.e. no 
busy signals) . Another example might be a variation which 
would allow recorded voice messages to be dispersed by the 
computer, similar to what a telephone answering machine does 
fcr incoming calls, allowing the message to be sent to mere 
than one destination. This would relieve *he originator of 
the time consuming task of calling a lot of erher people and 
getting many busy siqnals. 

The idea of messaging can be extended to having a 
computer conference where the messages are sent back and 
forth in an online mode, thus alleviating the need to have 
actual personnel travel to one geographic site in order to 
conduct the conference. Since some people find conferencing 
by computer too impersonal and hard to follow, the next 
extension is to transmit video signals, or teleconferencing. 
The Coast Guard presently has some systems capable of elec- 
tronic mail type messaging, although long distance systems 
are net in place at this time. Continued growth in this 
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area can be expected given the rising costs of transporting 
personnel and the decreasing costs of computer and telecon- 
ferencing systems. 

3 . Eistribu ted S yst eras and Networks 

The concept of distributing computing resources 
(hardware, software, and data) is currently a major topic 
throughout the computer industry. A tremendous amount of 
research is being conducted in looking at how computer 
networks and distributed systems can improve the effective- 
ness and user satisfaction of today's information systems. 
The researchers will use the following definition of a 
distrtuted systeii: first, the system should possess two or 

mere geographically separated processors, second, the 
processors should be linked, and third, the processors 
should serve a single organizational entity. Computer 
networks can be generally defined as a connection of two or 
more computers vhich are able .to communicate between one 
another. Examples of computer networks include the Advanced 
Research Projects Agency (ARPA) Network and IBM's System 
Network Architecture (SNA). Note that a distributed system 
is a computer network, but not every computer network is a 
distributed system [Ref. 8]. 

As previously mentioned, the Coast Guard has decided 
on a principle cf distribution of computing resources to 
some extent. The Coast Guard will build upon message 
store-and-forwa r d communication as its principal mode of 
interconnection. True computer processor interconnection in 
the style of IBS's SNA will be discouraged for the near 
term.- The reason for this policy is based on the principle 
of prudent evolution. There is no forseer. great payback to 
the Coast Guard for implementing comDuter networking of the 
SNA-type systems at this time, especially considering the 
high technical- s kill and supports costs of SNA [Ref. 4], An 
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important point the Coast Guard should consider when imple- 
menting its present systems is to design for future change 
and recognize that computer networking and distributed 
systems are the direction information systems are headed. 
Therefore, the Coast Guard should strive fcr compatibility 
and standardization as much as possible in order to have 
systems capable cf becoming networks when such a configura- 
tion is considered economically feasible ar.d desirable. 

4. Dec isio n Su ppc rt Systems (DSS) 

Decision Support System is also currently a highly 
discussed topic in the computer field today. Some consider 
it to be the latest ’buzz-word* in the industry, picking up 
where Management Information Systems (MIS) left off. Many 
critics feel that DSSs are no different than MISs and that 
the new term has simply evolved so that salesmen can sell 
more systems. Eut many others, including the researchers, 
feel that DSS is an independent concept, and that it refers 
tc building an information system to be readily utilized 
primarily tc support the decisions which an individual in 
the organization has to make. Some components of a DSS 
would probably include: an interactive query or dialogue 

capability, a database management system, a modeling capa- 
bility, and a graphics capability. Some observers consider 
the modeling capability as the feature which distinguishes a 
DSS from an MIS, while others believe its distinction to be 
that it is primarily designed for the particular ir.divdual 
or job position for whose decisions it is meant to support. 

At any rate, the researchers feel that the Coast 
Guard will most likely be investing in decision support 
systems in the future, as these systems seem to fall nicely 
into the goals and objectives which the Coast Guard has set 
for its Command, Control and Communications program. The 
researchers are aware of at leasr one DSS in use in the 
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Coast Guard which is installed in the First Coast Guard 
District in support cf the operations center controller for 
search and rescue decision making. 

5. Fata Base Management Systems 

This thesis discusses in some detail the status of, 
goals and obiectives of database management systems. The 
researchers believe that the Coast Guard is realizing the 
importance of DBKS, and specific recommendations regarding a 
strategy for implementing database technology are included 
in Chapter VI. 

The Coast Guard is in varying stages of installing 
database technology. The Marine Safety Information System 
(MS IS ) has been in development for over 10 years and will 
contain a sophisticated DBMS. With regard to the District 
minicomputer procurement, the Wilson-Hill study, [Ref. 10], 
has beer, viewed as a 'jumping off* point for developing the 
logical data base design tc be utilized by the Coast Guard 
Districts. A pilot project for designing the logical data- 
base is underway in the First Coast Guard District and it 
has been reported that they are attempting to integrate the 
Districts' database requirements for this design with those 
of other Coast Guard organizational elements. This will 
hopefully ensure a standard Coast Guard data dictionary, 
which the researchers believe is essential for the success 
of this project. A target date of April 1983 has been 
projected for the initial draft of this design. 

The authors will next discuss some of the factors 
which may influence the Coast Guard in pursuit of the goals 
of the Command, Control and Communication program. 
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C. INFLUENCING FACTORS 



The researchers believe that the following factors 
organizational change, resistance to change, - 1 : echnological 
change, government procurement regulations, and support 
requirements - will most likely have some impact on the 
Coast Guard as a result of installing information in data- 
base management systems. The authors will proceed to 
discuss these implications in more detail and describe what 
effects they may cause in a n organization. 

The first factor which may have an impact on the Coast 
Guard ir. implementing database technology and other informa- 
tion resource management goals, in fact, already has 
occurred - organizational change. As was mentioned, one of 
the initial events which triggered the Coast Guard's 
emphasis on information and data resource management was the 
reorganization of the Headquarter's divisions of OTH, EEE 
and FIS into the Office of G-T. But there are other less 
evident ways in which the introduction of dara base tech- 
nology may change the organization. These changes will be 
in the way in which particular individuals perform their job 
and also in the informal organizational structure of the 
Coast Guard. Hopefully, the new systems will improve or 
make easier the tasks which Coast Guard personnel carry out. 
This is one of the reasons -‘-he new systems were introduced 
in the first place. The informal structure of the organiza- 
tion refers to the fact than in order to get things 
accomplished, the formal organizational structure is not 
always strictly followed, and informal working relationships 
often crop up. By introducing new technology, changes in 
this informal structure can be expected as new users of the 
systems interact with other users who either work in a 
similar manner with the system, or are more knowledgeable. 
The effects of the changes can be beneficial or harmful 
depending upon the productivity of these relationships. 
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The next factor which might influence the Coast Guard in 
this area is resistance to change. By this, the researchers 
are referring tc the idea that no matter how much one 
prepares for changes in the organization, there should be 
some expectation that not every one is going to accept the 
new sysxem (i.e. there will be resistance). These may 
appear such as a senior enlisted radioman who becomes 
disgruntled at the thought of having a computer take over 
the job he used to dc; or providing a computerized sysxem, 
such as computerized inventory system, to an employee who 
developed the old system and is highly familiar with it. 
These types of personnel can be expected to 'buck' the new 
system and therefore their reactions should be considered in- 
order to make the system work, because without their 

interest, involvement and support, the new system will most 
likely fail. 

Other factors which should be considered are xhe impact 
of new technology, and the effect of Government procurement 
policies and regulations. Technology in the computer 
industry seems to continue to improve upon itself at an 
amazing rate. Yet forecasters predicx that technology in 
the computer industry will contiue to get better, and there- 
fore the Coast Guard must be aware of this improving 
environment and be ready to take advantage of it. The 
authors believe that the Coast Guard should strive to 
acquire homogeneous systems whenever possible. This will be 
discussed in Chapter VI. It is noted that the Brooks Act 
seems directly contrary tc this goal in the interest of 
stimulating competition in the industry. Other regulations 
such as GSA having sole procurement authority over ADP 
equipment must be taken into account when planning for and 
acquiring new systems. One might think that the bureauc- 
ratic procurement regulations of the Federal government 
would be something that the Coast Guard should be well aware 
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of; tut, as discussed, for the most part the Coast Guard is 
really cr.ly now purchasing its own computer systems having 
leased timesharing service primarily in the past. Therefore 
the Coast Guard should take heed of the lessons learned by 
ether Federal agencies, particularly the Department of 
Defense, with regard to the long lead times involved in 
procuring ADP eguipment and plan early to spend a consider- 
able amount of effort in order to keep up-to-date systems. 
Another major factor the Coast Guard must contend with is 
the supperr requirements necessary for these systems to 
properly function. These requirements include: personnel, 

facilties, training, maintenance (of both hardware and soft- 
ware) , security, and perhaps most importantly, dollars. The 
first couple of requirements are somewhat obvious in that 
everyone should realize that computer systems need people to 
run them, buildings to put them in, cables to run between 
them, etc. The aspect of training can often be overlooked, 
especially when one considers the importance of follow-on 
training. Table IV [Ref. 11] is an example of the training 
needs of the d eta base administrator and staff in a DBMS 
environment. This list indicates the extensive training 
required to ensure proper operation of the system, and also 
the need to have competent professionals working with the 
system in order to educate the non-sophisticated user (of 
which there is likely to be a majority of in the Coast 
Guard, at least initially). 

Maintenance cf hardware is not considered to be an over- 
whelming constraint, as hardware systems have become more 
and more reliable, but backup procedures must be planned for 
in the case of hardware failures. The biggest factor in the 
maintenance area is that of software maintenance. Hera 
again if must be pointed out that the Coast Guard is rela- 
tively new in the computer business and therefore there is 
not a lot of experience in dealing with computer systems. 
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TABLE IV 

Duties of DBA and Staff in a DBMS Environment 






DESIGN AND AD INSISTS ATI ON 
Define schemas and subschemas 
Select and maintain data model 
Select and maintain DBMS software 

AD MINI ST NATION 

Liaison with users 

Training and assistance of users 

OPERATION 

Formulate and enforce procedures for security S privacy 
Initiate and enforce procedures for recovery S integrity 
Define, create, update, and retire data 

MONITORING 

Measure and monitor performance of DBMS resources 
Log and monitor usage of DBMS resources 
Schedule usage 
Monitor security threats 

I i 



As these systems become available, more and more programs 
(software) will inevitably be written. Therefore software 
engineering principals need to be stressed early on so that 
the software written today can be maintained tomorrow. 
Experience from EoD has shown that software maintenance is a 
tremendous concern and is probably the largest expenditure 
on DoD computer systems today. DBMS should aid in this area 
by introducing the concept of data independence into 
programs written for Coast Guard computers equipped with 
such systems. 
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Security refers tc the concept that the physical compo- 
nents must be protected from threats such as theft, 
vandalism, and natural disasters, as well as protecting the 
privacy and confidentially of the data stored within the 
system. Security should be a primary consideration of any 
computer installation and DBMS should assist by providing 
access control, integrity checks, security and auditing 
features . 

The last item mentioned is probably a result of faking 
care of some of the ether factors which were discussed, and 
this implies that if takes money to properly install and 
operate an information system. The Coast Guard must realize 
that it is going to take a considerable amount of additional 
funding in order tc properly operate, maintain and keep 
current the computer information systems it is installing 
today . 
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Along with this 'design for change' concept goes the 
principle cf requiring good documentation for all the 
systems which are acquired. This concept is especially 
crucial in a military organization where personnel rotation 
policies guarantee that almost all the people who are 
present when a new system is installed will probably be gone 
after 2-4 years. This factor indicates that the documenta- 
tion cf the system had better be sufficient and up-to-date 
in order for new personnel to understand, operate and main- 
tain the system. The Coast Guard can learn another lesson 
from EoD , which has reported many instances of poor documen- 
tation cf systems which after a short while, led to a 
situation where no one really knew how the system worked. 
Therefore, if the Coast Guard expects to be able to under- 
stand and maintain its systems, good documen+ation is vital. 

Another factor which will help minimize negative impli- 
cations is for the Coast Guard to maintain top level support 
of its information management, goals. If top level support 
exists, then the chances of success are much greater; 
however, if this support is not evident, then failure is 
almost assured. This statement seems most obvious, but it 
appears to the researchers that it is often overlooked. One 
problem involved here may be that the technology associated 
with the information systems which are being introduced 
today is probably much different than what most top level 
managers are experienced with. This could lead to intimida- 
tion of the senior level supervisors to the point that they 
will avoid using computers in order that they do not appear 
ignorant in front cf their subordinates. If the senior 
level managers are not using the systems, then their subor- 
dinates may not feel inclined to use them and eventually the 
funds to support the systems might be cut or even shut off 
completely. Therefore cod level support can be seen to be 
an important ingredient to the success of a system, but how 
can this senior level support be achieved? 
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This question leads into the next point which is the 
importance of hunan needs. The researchers feel that one of 
the best ways in which to achieve *op level support for a 
system is to have them involved with and using the system. 
It has already teen mentioned that senior level personnel 
may be intimidated by a computer, and it should be noted 
that they probably don’t have a lot of extra time to spend 
learning how to use the system. Therefore one way to get 
them tc use it is to make the system easy to learn and easy 
to use. Reference 12 points out some excellent general 
design principles which should characterize a user oriented 
interactive system. These principles include: 

1. Self explanatory - the system should display suffi- 
cient information to the user without having to go to 
another source for explanation. 

2. Self helpina - the system should provide, a checking 
of user inputs and reminders or further instructions 
on user request. 

3. Simple interfacing - the system only requires actions 
which are short, simple and obvious. 

4. Interaction by anticipation - the system anticipates 
all possible desires of the user in advance and 
provides prompts or menus so that the user can select 
the desired option in lieu of explicitly specifying 
it . 

5. Optional verbosity - the system provides another 
level(s) of detail so that the user can obtain more 
detailed information cn a particular item, if so 
desired [Ref. 12]. 

By utilizing these design principles, most systems would 
be easier to learn by most users. But even with these 
features, seme personnel are going to require a lot of 
’hand-holding' and training to be a satisfied user. Another 
important item to remember when designing a system is to 
always include representat ives of the end users in the 
design committee . This will often turn up obvious problems 
and peculiar needs by the end user representatives which 
would not have turned up from the other design committee 
members and thereby saving a lot of expense altering the 
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system just after installation. This membership on the 
design committee also helps promote a feeling of early 
involvement with the new system which can help cut down on 
the resistance tc change. 

The bottom line is that system designers must take into 
account the needs, capabilities, and shortcomings of the 
human user in order that the system be responsive to user 
requirements, easy tc learn and easy to use. 

E. SUMMARY 

In summary, this chapter pointed out several organiza- 
tional implications such as organizational change, 
resistance to change, and support requirements which the 
Coast Guard should consider when planning for information 
systems. The researchers believe that the Coast Guard is 
headed in the richt direction with its information and data 
resource management policies, and that good implementation 
practices are being followed by the Coast Guard. Coast 
Guard system designers must take into account human needs 
and shortcomings so that the information systems it employs 
are usable as well as efficiency and productivity 

impro vement s. 

The following chapters of this thesis will proceed to 
discuss data/dat abase management techniques and trends, and 
then investigate the alternatives open to the Coast Guard. 
The researchers will match the Coast Guard's particular 
needs against the various DBMS alternatives available and 
make recommendations as to the direction the Coast Guard 
should take in this area. 
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IV. FOTORE TEC H NOLO GY DEVELOPMENTS 



A. GENERAL 

Before proceeding further, it is advantageous to explore 
the new technologies that are evolving today. In the field 
of computing, it is not surprising to see advances in tech- 
nology that make the equipment, policies, and practices 
obsolete in just five or ten years. Eor example, the 
computer industry's architecture has progressed through four 
generations of machines in thirty years - from electrical 
accounting machires (EAM) to vacuum tubes to transisrors to 
integrated circuits. Similar growth has been experienced in 
the logical viev and management of data; flat files with 
reccr d-at-a-t ime serial access, to indexed sequential files 
capable of random access to data, to sophisicated data 
bases. The physical level is no exception either as IK bit 
chips were used in the late 1960's while today 64K bit chips 
are standard in most machines with 256 k bit chips available 
or. some. 

Any strategy must take into consideration the impact of 
technology. Therefore, this chapter will discuss those 
items that + oday promise to have the most impact on database 
management systems (DBMS) in the next five to ten year time 
frame. The most promising areas are in mass storage hard- 
ware and software, memory, database machines, and 
distributed database manage menu systems. 

Although the conceptual views of DBMSs have gone through 
technological changes, these views have more or less settled 
down into three basic models - hierarchical, network or 
plex, and relational. These models will be discussed in a 
later chapter. 
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B. ASSOCIATIVE COMPUTER ARCHITECTURE 



Traditionally, access to data in main memory has been 
accomplished by hardware address. This is a necessary 
consequence of the von Neumann computer architecture. 

However, the most desirable way to access non-numeric data 
is by value. Erogrammers and users of computer systems, 
especially those employing DBMSs, think of problems and 
solutions in terns of value, not hardware address. As the 
computer industry matured, a number of methods were used to 
convert an external value in^o an internal computer or peri- 
pheral device address. Most of these methods are still in 
use today, e. g. sequential, indexed, hashed, and set access 
met hods . 

As data bases became larger and larger, and access was 
required to more and more data, computer performance was 
kept to an acceptable level by brute-force improvements in 
hardware speed; i.e. integrated circuits, more bits per 
chip, etc. The cne basic element that never changed was the 
von Neumann architecture. Today, computer scienrisrs are 
beginning *o rethink the foundation on which computer 
science has been built and are investigating contents 
addressable memory, or associative storage. 

Associative processing systems generally have the 
following five basic components - data register, mask 
register, data array, word select register, and search 
results register. As shown in Figure 4.1 [Ref. 13] the Data 
Register contains the value to be searched, while the Mask 
Register indicates what par* of rhe Data Register is to be 
used for the search. The Data Array contains the data to be 
searched, the Sera Select Register indicares which words in 
the Data Array are to be checked, and the Search Results 
Register contains a * 1* bit for those values in which there 
was a match. A Multiple Match Resolver indicates which 
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Figure 4.1 associative System. 

value was found first. From a casual inspection of Figure 
4.1 it is apparent that the size of the Data Array contains 
an upper bound which limits the size of a data base that can 
be searched using parallel associative s + ore in a single 
storage cycle. Shat is typically being done is a sequential 
associative search on large portions of sequentially stored 
data. This gives the logical effect of parallel associative 
store if not the speed. 

This type of architecture is being experimented with 
today in a number of ways. One idea is to build an intelli- 
gent controller based upon associative processing, and place 
it between a general purpose computer (which contains the 
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DBMS software) and rhe mass secondary storage device cf rh<=» 
data base. The intelligent controller would accept a parsed 
request from the computer, and process the transaction 
against the data base. Another approach is to incorporate 
this archit c ctur e into the computer itself. More will be 
said cf this later. 

c. BFMOBY 

The driving force behind the rapid advances in the 
computer industry has been microelectronics. The growth 
depicted in Figure 4.2 [Ref. 14 ] was predicted in 1964 by 
Gordon Moore, the director of research at Fairchild 

Semicondutor . To date the curve has been pretty accurate. 
Whether or not this trend continues is speculative, but 
current technology has not reached its limit with regards to 
physical laws. Further, as the number cf components per 
circuit increases, the cost per bit drops; one cent per bit 
using IK chips in the late 1960’s to one tenth of a cent per 
bit using 64K chips in 1979. These developments, especially 
with respect to main memory storage, have great consequence 
for DBMSs, because main memory serves as a buffer area to 
operate secondary mass storage. The larger the main memory, 
the fewer I/O interrupts required to accomplish a process. 
Hence, performance requirements for large data bases can be 
kept to within acceptable limits as sizable portions of a 
data base can be kept in main memory without having the 
processor page data in and cur of secondary mass storage. 

Secondary storage devices too have been developing at a 
similar rate. Charged coupled devices (CCD) are available 
in 64K chips with 256K chips soon becoming available. 
Bubble memory is available, but it is not as popular as CCD, 
perhaps because it has slower access times for large amounts 
of data. Research is still on-going in this area. 
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Figure 4.2 Growth in Microelectronics . 

D. DATAEASE MACHINES 

Today when people talk of database machines, there is no 
common agreement on the architecture. In fact anything from 
a master-slave configuration (a general purpose processor 
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* 



which performs all of the data base activities) to a special 
purpose hack-end with intelligent controller, is considered 
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Figure 4.4 Future DBMS Architectures. 

tc have a database machine architecture. Figures 4.3 and 
4.4 are some of the ways DEMSs are integrated in computer 
architecture, both present and future. The underlying 
concept of a database computer, regardless of the given 
configuration, is to off-load a portion or ail of the DBMS 
system functions from the general purpose CPU. This 
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approach probably had its impetus in the front-end proces- 
sors which isolated complex and sophisticated communications 
and message processing capabilities, and placed those func- 
tions in a specially designed separate processor. 

There are a number of factors today which make the off- 
loading of DBMS functions very desirable. First, user 
application requirements are requiring larger and larger 
data bases. The very volume of data is beginning to create 
performance problems with the length of time necessary to 
locate the data. In some cases the overhead for indexes and 
tables consumes more than the data itself. Typical issues 
any DBMS must address are (1) the organization of an inte- 
grated data base, (2) the storage locations for data in the 
system, (3) the location of data in the system, (4) the 
control of concurrent addresses and (5) -he mechanisms and 
structures to provide security and integrity. In addition, 
more and more functions are being required in the DBMS. As 
the variety of these functions of a DBMS increase, so does 
its overhead with an accompanyinq reduction in response time 
and throughput. 

The first attempts to ease the overhead and performance 
problems of DBMS's consisted of using a general purpose 
back-end computer to replace database management software, 
on I/C routines, and on-line secondary storage. Although 
this has provided a partial solution to the bottleneck prob- 
lems, the following factors have mitigated against its 
popularity. The marginal value of a general purpose 
back-end computer's performance are in most cas°s much less 
than the marginal costs of the machine, it is not uncommon 
to have multiverdor coordination difficulties, and reli- 
ability of the total system went down as a result of using 
both the host and back-end (if one goes down the whole 
system crashes.) 
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By specialization, i. e. associative addressing in an. 
intelligent I/O controller (discussed earlier) , in conjunc- 
tion with special purpose hardware, significant improvements 
result which ease the performance bottlenecks of present-day 
software-laden DEMS. The reason, in a special designed 
processor the need for floating point hardware, long-word- 
size registers, and fast multiply and divide logic are not 
required. Instead, byte manipulation and high speed I/O 
capability to a wide variety of storage devices can be 
accommodated, providing the potential for significant 
improvements. There is much research needed in this area, 
but it shows son® premise, and is attracting some of the 
best minds in industry and the academic environment. For 
example, Sperry Onivac is working with Dr. David K. Hsiao in 
exploring the coirmerical potential for his DataBase Computer 
[Ref. 13: p. 1], 

E. DISTRIBUTED EBHS 

Another approach being explored to solve the bottleneck 
performance problem of DBMS software, distributed data-base 
technology, attacks the problem from an altogether different 
perspective. The major benefits claimed are increased data 
availability to the end user and reduced exposure to total 
system failure due to hardware or software failure 

[Ref. 15]. Because data processing and storage capabilities 
are distributed to the location of data origin or end use, 
faster and easier access to the data can be provided than 
under a traditional centralized DBMS. However the facili- 
ties for data organization access and control must be 
extended to include the following CODASYL recommendations in 
a Network DataBase Management System (NDBMS) : 

1. Intercept a user request and determine which nodes to 
send if to for processing. The majority of user 
requests should use local data and not require the 
NDEMS. These may go to the local DBMS directly or be 
passed to it by the NDEMS. 
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2. Access the network directory (which may possibly be 
remote) for the above purpose. 

3. If the target data are on multiple nodes, coordinate 
the use of these nodes. 

4. Manage the communication between its node and DBMS's 
in ether nodes. 

5. Provide da + a and process translation support in a 
heterogeneous distributed data-base environment. 
Heterogeneousness in this context implies differences 
between hardware (and software) elements in each node 
in the system. 

Thus in distributed data base technology, faster access to 
data introduces nore complexity to the overall system. 

Maintaining data base accuracy with concurrent updates 
to the same data item, maintaining the internal consistency 
of the data base, and maintaining the consistency among the 
various copies of the data base, collectively comprise what 
is known as concurrency control. This is the primary 
research area in distributed database technology. One may 
think that having heterogeneous hardware and software compo- 
nents might create the most difficulty in a distributed 
system, but this is not so. Heterogeneousness does however, 
add to -he complexity of the system. It is believed that 
before a distributed DBMS can achieve wide acce ptability , 
the update synchronization or concurrency problem must be 
sol ved. 

A number of methods or techniques are being explored to 
solve the update synchronization problem [Hef. 16]. The 
first is global locking where all the copies of the data are 
locked, the update is applied to every copy, and all the 
locks are then released. This approach effectively solves 
the concurrency problem, but at an unacceptable price in 
high system overhead. The second method is dominant copy 
synchronization where one copy in the distributed system is 
dominant and updated first. This dominant copy then 
controls the rest of the updates at the different nodes. 
This method is acceptable for systems having low updat® 
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frequency, tut becomes the source of a bottleneck if updates 
are high, or if updates are time critical. The third method 
utilizes timestamps instead of locks. The idea presented is 
that timestamps are appended to every data item. The data 
an the node can be updated if the timestamp is greater (more 
recent) than the timestamp on the data items at the node. 
The concern with this approach is the storage burden created 
by the timestamp being appended to every data item. A time- 
stamp for every record versus data item effectively cuts 
storage requirements, bu* some needless conflicts are 
incurred and some updates are delayed with this approach. 

The Department of Defense has contracted with Computer 
Corporation of America (CCA) to investigate the feasibility 
of utilizing distributed database technology for command and 
control situations. CCA's result has been the development 
of the sysrem for Distributed Database (SDD-1) which appears 
to have elegantly solved the concurrency control problem. 
As this development has generated much interest, in the 
research field, a brief description is provided in Appendix 
E which provides insight to net only the concurrency problem 
in distributed database technology, but also the technical 
problems of query processing and reliable writing. 

Research is cn- going in this area and much work has to 
be done before it can be effectively used by an organization 
that is not technologically sophisticat ed. 

F. SOHHARY 

The requirements into the foreseeable future will 
require DEMSs to deal with higher and higher transaction 
rates, larger data bases, and more complex queries to 
minimize the number cf reports received by the end user. 
Figure 4.3 depicts those architectures that are commonly 
available today. The most common architecture is having the 
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DBMS, hcst language interface, and query language capabili- 
ties collocated. Where the CPO is utilized more than 45% to 
perform data base functions, off-loading the DBMS functions 
into a back-end processor as in Figure 4.3 may be cost 
effective [Ref. 17]. But this is only a partial solution to 
the growing requirements. 

The technological developments in associative 
processing, very large scale integration (VLSI) chips, and 
database machines, will make architectures like Figure 4.4 
possible with much better cost/perf ormance ratios. These 
configurations are not commercially available today. 

Further Coast Guard requirements do not call for them at the 
present time. But a DBMS strategy must recognize that 

future requirements will outstrip what is available today. 
Solutions to expanded requirements will more than likely 
find their source in the emerging technoloay, and any corpo- 
rate strategy must take cognizance of this. 
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V. CURRENTLY AV&IL ABLE DBMS ARCHITECTURES 
A. GENERAL 

One can categorize database systems by the form of the 
data model that is used, e. g. relational, hierarchical, and 
network. The primary characteristic of a relational model 
is that all information in the database is represented in a 
single uniform manner, namely in the form of tables. This 
data model supports many-tc-many relationships of data. The 
characteristic of the hierarchical model is that information 
is represented by a simple tree structure. Each node in the 
tree can be likened to a single file; however, these files 
are a more complex object than the tables of the relational 
model. First, the file may contain more than one type of 
record, and second there are links connecting occurences 
(instances) 'of these records. Hence, the data in a hier- 
archical model is represented by records and links in a 
one-to-many relationship. The characteristic of the network 
model is that information is represented by records and 
links as in the hierarchical model, but the network model 
has the capability of modelling many-f o-many relationships 
like the relational model. 

Since the cifference between the network (sometimes 
referred to as CCDASYL (Conference on Data System 
Languages)) and relational approaches to DBMSs are such a 
controversial topic at the present time, this chapter begins 
with a discussion abcut the distinctions between the CQDASYL 
and relational approaches to database management. The only 
goal here is to present the views of the authors and what 
they understand the difference to be in the approaches. 
After a somewhat lengthy discussion of the relational versus 
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CODASYL approaches, a discussion of a particular data model 
from each of the three current available DBMS architectures 
is presented. The objective is to provide the reader with a 
feel for what each data model offers - its strengths and 
weaknesses - not to evaluate all DBMSs available on the 
market today. A t the end of the chapter the consequences of 
choosing one DBMS architecture over another are discussed as 
a prelude to the next chapter on a database management 
strategy. 

B. RELATIONAL A FD CCDASYL NETWORKS 

To understand the difference between the relational and 
CODASYL (network) approach to DBMSs, it is necessary to 
understand the three-level hierarchial view of a data base. 
The Standards, Elanning and Requirements Committee (SPARC) 
and the American National Standards Institute (ANSI) 
published an interim report in 1975 defining this three- 
level structure. The programmers view of data is referred 
to as the external s c he ma. The overall logical view or what 
one may consider the corporate view of data is called the 
conc e ptu al s c he m a. Finally the physical organization cf the 
data itself is Known as the internal sche ma . Figure 5.1 
depicts the three different levels. 

The internal schema is one whose records are manipulated 
by READ, WRITE, and DELETE commands of COBOL and PL/I. At 
this level one notices that a file has not only data, bu* 
flag and pointer fields to handle overflow in a hash file. 

(There exist other methods tc organize the data physically; 
however, for purposes of illustration the file under discus- 
sion is assumed to be a hash file. The idea of a hash file 
organization is to divide the records cf a file among 
buckets, which each consist of one or more blocks of 
storage. If v is a key value, h(v) indicates the number of 



66 



BTbTS 3 

EXTERNAL FILE 1 






USERl_APPLI CATION 
Call CONCEPTUAL LEV^L 



USER2_APPLICATION 
Call CONCEPTUAL LEVfe: 



< 

el 



EXTERNAL FILE 2 




EXTERNAL SCHEMA 




^a CDElFlaa l^^ 



Subroutines STORAGE_LEVEL 
Read File (STORAGE FILE) into 



INTERNAL SCHEMA 



Figure 5.1 Three-Level Hierarchy of a DBMS. 

the bucket in which the record with key value v is to be 
found.) At the conceptual schema level the flag and pointer 
fields are of no interest; in face they would just clutter 
the file with meaninaless data for the dara base 
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administrator or the corporate user. At the highest level, 
the external schema, each programmer or user is only 
concerned with a portion of the conceptual schema. Thus 

external files and the fields of an external file are a 
subset of the fields of the underlying conceptual schema. 
The external schema contains no flags or pointers from the 
internal schema, only data of interest to the data base 
administrator or corporation. It should be pointed out that 
the fields in the external file may be derivable from the 
conceptual schema. As an example the field 'age' in the 
external schema is derivable from the field 'date-o f-birth' 
in the conceptual schema. .(Note these are two different 
data elements; one is probably represented as '480605' 
(conceptual schema) and the other as ' 34 * (external 
schema) ) . 

There are sene important consequences flowing from this 
type of design. If fer some reason the database became used 
heavily for sequential access, reads and writes, it should 
be possible to change the internal schema without affecting 
either the data base administrator's view or use of the 
data. Also the programmer or user (the external schema) 
should net become embroiled or tangled with changes made at 
the internal schema level. This is commonly referred to as 
p hysi cal data inde p enden ce. Another closely associated 
concept is looical data in depen d en ce. Here programmer E can 

add another field to his external schema. If the field is 
in or can be derivable from the conceptual schema then not 
much effort is required tc provide Programmer B with the 
desired field. However, if a field is requested that is not 
in the conceptual schema then the conceptual and internal 
schemas will have some work to do. Logical data indepen- 
dence is achieved when programmer A's application is not 
affected by the changes required to make a new field 
available tc Programmer 3. The benefits that follow from 
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physical and logical data independence are lower maintenance 
cost and less programmer time. Beth the relational and 
CODASYL data models have embraced the three-level concept. 

The core of understanding the difference between these 
data models lies in the conceptual schema. One can view the 
conceptual schema three ways: 

1. The same as the internal schema without its implemen- 
tation of flags and pointers. 

2. A common derominator logical file for all users. 

3. A collection of conceptual records, each of which 
describes an entity of the real world. 

In the relational mcdel, a relation (table) is the same as a 
conceptual schema in which no two records (sometimes 
referred to as tuples) are the same (i.e. no duplicate 
records). Further, a relation can be displayed as a two- 
dimensional matrix, where a row of the matrix is unique and 
corresponds to a record. (It is important to realize that a 
relation cannot be compared with a conventional file as the 
file is a storage file that physically exists. This is not 
so with the relation which can only be understood in terms 
of conceptual schemas.) Just because a relation is equiva- 
lent to a conceptual schema, where no twe records are the 
same, does not mean that there exists conceptual schemas 
that are not relations. For instance, any number of 
repeating groups or fields can exist and are permitted in a 
CODASYL conceptual schema. If there are repeating groups or 
duplicate records in the conceptual schema, then the concep- 
tual schema is not a relation. Hence the underlying 
difference between the two approaches. 

The conceptual schema of the relational model imparts 
simplicity as external schemas derived from conceptual 
schemas are also relations. Further, the simplicity of the 
relational's external schemas make them easy and convenient 
to manipulate via application programs. The relationship 



69 



between the conceptual matrices are r.o + explicitly specified 
(i. e. named) in the conceptual schema for a relation, the 
specification of the connection fields supporting the rela- 
tionship being necessary and sufficient. For example it is 
the connection fields OPS CNTL in AREA COMMANDER and OP CNTL 



| OPS_CNTL | 



HQ 



I 



1LANTAREA | New York | 

PACAREA | San Francisco | 

AREA COMMANDERS 



SKIP NC 


| 0 PS CNTL 


1 


SHIP_TYPE 


W AGB-10 


| PACAREA 


~ 1 - 
1 


ICEBREAKER 


WAG5-11 ] 


| PACAREA 


I 


ICEBREAKER 


W EEC -7 16 


| LANTAREA 


1 


HEC 


, W HEC-721 | 


| LANTAREA 


1 


HEC 


| W EEC-723 


| PACAREA 


1 


HEC 


W?EC-618 1 


1 LANTAREA 


1 


MEC 


W MEC -620 


1 PACAREA 


1 


MEC 



VESSELS 



Figure 5.2 Example of Two Relations. 

in VESSEL from Figure 5.2 that determines the relationship 

between the two conceptual matrices. This does create some 

difficulty when designing a retrieval language which is 

suitable for the nonmathema tica 1 user. Consider: 

SELECT FFOM AREA COMMANDER WHERE 
OPS CKTL IS ITT 

TSELECT OPS CNTL FROM VESSEL 

WHERE Srll F_TYPE = 'ICEBREAKER') 

Here one is asking for the AREA_COMMANDER record whose 

OPS_CNTL field values from VESSEL records for which the 

SHIP_TYFE is ICEEREAKER. Very convoluted to say the least. 
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In contrast, in CODASYL, the files of the external and 
internal schemas can become very difficult to manipulate via 
external programs if the records of the schemas contain 
varying numbers cf repeating groups of fields. The under- 
lying reason is that the data structures are allowed to 
vary. In a CODASYL conceptual schema the records are typi- 
cally grouped in two distinct ways. First, records of the 
same type are grouped toget her. This grouping is similar to 
the grouping of tuples (rows) in a relation; however, the 
CODASYL files that make up the conceptual schemas don' 1- , have 
to be relations, i.e. may contain repeating groups. The 
second method of grouping is into owner-coupled sets. In a 
set based on two files like in Figure 5.2 each owner record 
is grouped with its member record giving the grouping 



OPS CNTL 



HC 



< ->SHIP NO 



OPS CNTLISHIF TYPE 



LANT AREA 
PACAREA 



New York <->WHEC-716 

New York <->WHEC-721 

New York < ->WM EC-6 18 

San Fr ancisco< ->WAG3-1 0 
San Francisco< ->WAGB-1 1 
San Francisco<->WHEC-723 
San Francisco< ->WMEC-620 
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MEC 
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i 



I 

j 



Figure 5.3 Owner-Coupled Set Occurrence. 

* 

depicted in Figure 5.3. The relationship between the 
records cf J -he two files is clear. CODASYL requires that 
this grouping in Figure 5. 3 be given a name in the concep- 
tual schema. The CODASYL query could be expressed in terms 
like; 
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Retreive the owner record of each owner- 
coupled set cccurance in which all but 
cne of the member records have a SHIP TYPE 
value equal to ICEBREAKER. 

Hence, as the relational approach asserts that groupings of 
files is net necessary in a conceptual database, CODASYL 
requires it. Per the non -mathemati can certainly CODAYSL's 
grouping is easier to comprehend. 

In summary then, relational databases require a unique 
key for every record type, a means of representing set type 
relationships, and propagation of prime keys down the struc- 
ture [Ref. 18], The propagation of prime keys down the 
structure makes it very difficult for the user to form a 
correct query via the retrieval language of the database 
system. In contrast CODASYL does not force a data base 
designer to propagate prime keys down the structure; thus 
allowing English-like queries on the database. However, 
there is nothing in CODASYL to prevent conceptual files from 
being designed with repeating groups, duplicate records, 
etc., thus creating data structure problems in the future 
when structures have to be changed. 

C. RELATIONAL - SYSTEM R 

On 30 January 1981 I EM announced a product called 
SQL/Data System. This system is a relational DBMS. To the 
users of SQL/DS the data in the data base appears to be 
structured in the ferm of tables. The SQL/DS DBMS is the 
result of IBM’s work cn the prototype System R. 

1 . Cap abll i ties/Chara c teri sti es 

Seme of the claimed capabilities of SQL/DS are auto- 
matic navigation through the data base and automatic 
optimization. The user of the DBMS specifies what they 
want, not how tc get to the data they want. This 
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description of ’how' is performed by the very high-level 
language, SQL. This language has the ability to, manipulate 

collections of records not just single records. SQL also 
acts as a host language interface to COBOL, PL/I, and 
Assembler, i.e. SQL statements can be freely mixed with 
source statements from COBOL and PL/I. Besides being a 
query language SQL encompasses data definition, bulk 
loading, updating, granting authorization, and database 
recovery. The goal of automatic optimization is achieved by 
allowing the user to dynamically change an index or key. 

SQL/D S appears to support the American National 
Standards Institute ANSI X3 SPARC study group's interim 
report on the three-level hierarchy view of a DBMS. This 
recommendation is that a DBMS should support an external 
view of the data base which insulates the details of the 
physical organization of the data base from the logical view 
of the data. This should in turn, insulate the overall 
logical structure of the data base from the programmer or 
user. 

As in most DEMSs, SQL/DS provides for data security 
via access control/authorization, concurrency control for 
both batch and interactive processing, recovery, and direc- 
tory management. System resources consumed depend on the 
complexity of the data base and the nature of the transac- 
tions; however, it is claimed by I3M that performance can be 
kept to within acceptable limits. 



2 . Critique 

During the past decade there has been much research 
and discussion about relational databases as the result of 
the papers and theoretical work done by Dr. Fdgar F. Codd. 
But, the number of commercially available relational DBMSs 
is rather limited. Table 7 and Table VI provide a compar- 
ison between three (3) commercially available relational 
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TABLE 7 

Data Definition, Manipulation, and Control Facilities 



Feature 


sqvds 


ORACLE 


INGRES 


Da Cl Definition Support 


Variable Length Hows 


Yee 


Yes 


Yes 


Null Values Supported 


Yes 


Yes 


No 


Dynamically Add New Coluims 


Yee 


Yes 


No 


Support Stored Commands 


Yes 


No 


NO 


Dynamic View Definition 
Automatic Elimination 


Yes 


Yee 


Yes 


Of Duplicate Rows 


Optional 


Optional 


Yes 


Dynamic Data Base Expansion 
Data Manipulation Support 


Yes-Utility 


Yes-Utility 


No-O/S Function 


Storage of View Text 


Yes 


Yes 


Yes 


Append Table Co Itself 


No 


No 


Yee 


Support for User Files 
Specify Disk the Table is 


No 


NO 


No 


To Be Placed On 


Yes 


No 


No 


Maximum Size Char. Field 


32767 . 


255 


255 


Define Synonyms 


Yee \ 


No 


NO 


Sort Query Results 


Yes 


Yee 


NO 


Data Conversion Functions 


No 


NO 


Yee 


Help Facility 


Yes 


NO 


Yee 


Integrity Constraints 


NO 


NO 


Yes-Single Table 


Three-Walking Syntax 


No 


Yes 


No 


Outer- Join Syntax 
Data Control Facilities 


NO 


Yes 


NO 


Access Permission for Tables 


and Views 


Yes 


Yee 


Yes 


Permission Structure 


Decentralized 


Decentralized 


Centralized 


Resource Authorization 


Yes 


No 


No 


Password for Data Base Acceee 


Yes 


Yes 


No 









databases [Ref. 19]. It is apparent that these three (3) 
systems provide a level of capability to support the Coast 
Guard's requirements; however, because they are relatively 
new products, items such as vendor support, documentation, 
and user satisfaction cannot be determined. 

D. NETWORK - COEASYL TYPE - TOTAL 

One cf the most popular DBMSs on the market today is 
Cincom's Systems, Inc. - TOTAL. They claim over 3,000 users 
of their DBMS. TOTAL supports the network data model by 
allowing a large number of files to be linked together. 
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TABLE 71 

Comparison of General Capabilities 



Feature 


SQL/DS 


ORACLE 


INGRES 


Index Support 








Primary Index Required 


NO 


Yea 


NO 


Support Dynamic Index Def. 


Yes 


NO 


Yes 


Support Multi column Indexes 


Yes 


No 


Yes 


Support Variable Length Keys 


Yes 


Yes 


Yes 


Physical Ordering of Data 








(Clustering) 


Yes 


Only on Initial Load 


Only on Initial Load 


Change Clustering Index 


No 


No 


Yes 


Locking 








Levels 


Row, Page, Table, 


Row, Table 


Table 




Data Space 






Automatic Lock Escalation 


Yes 


No 


No 


Storage Statistics Available 


Yes 


No 


Yes 1 

1 


'Optimization 






! 


Access Method 


Compiled ^ 


Interpretive 


1 

Interpretive « 


Path Selection Methods 


Evaluate Indexes , Scans 


Evaluate Indexes 


Evaluate Indexes, Scans 


» 


and Two Join Methods 




and One Join Method 


Transaction Management 






I 


Mult. Statement Transactions 


Yes 


Yes 


No 


User-Controlled Backout 


Yes 


No 


Yes 


Support Nested Transactions 


No 


Yes 


N/A 


Disk Recovery Techniques 


Roll Forward & Backout 


Roll Forward 


None 


Host Language Interface 








Type 


Precompiler 


Call 


Call 


Languages Supported 


PL/I, Cobol and 


Fortran , Cobol , PL/I 


Pascal & *C ' 




Assembler 


'C* and Assembler 




Support for Multiple Cursors 


Yes 


Yes 


NO 


Computer Environment 








CPUs 


43XX, 370, 303X 


PDP 11 /XX, VAX 


VAX 


Operating Systems 


VSE 


RSTS , RSX-1 1M , I AS , Unix, 


1 






VMS 


VMS j 



1 . Cap abil i x i es/C ha ra c t er i stie s 



Multiple phases a 
DEMS. First, <3ata base g 
done by describing files, f 
physical file characterist 
high-level Data Ease Defini 
and files have been formatt 



re required to produce TOTAL'S 
eneration is necessary. This is 
ile relationships, data elements, 
ics, and buffer usage via the 
tion Language (DEDL) . After data 
ed the Data Manipulation Language 
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(DHL) statements can be embedded in a hose language to begin 
actual processing of data. Access to the database is 
possible via FORTRAN, COBOL, FL/I, RPG II, and Assembler. A 
simple query language, T-ASK, and report generator, 
SOCRATES, is provided, but SOCRATES can only be executed in 
batch mode. 

Ccmmmon features found in other DBMSs are also found 
in TOTAL. One example is that new applications and files 
can be added to an existing data base or a new relationship 
can be defined for existing files without impacting previ- 
ously implemented applications and programs. TOTAL provides 
for integrity through izs automatic recovery system which 
restores the data base to its original condition pricr to 
the computer system cr program failure. Password prorecrion 
is provided at the file level. TOTAL supports both interac- 
tive and batch processing. Inconsistent updating is 

prevented via the use of record locking, i.e. when updating 
(writing) a record, ether processes are denied access to the 
recor d. 

2 . Cri tiqu e 

TOTAL is popular, and can be run on many machines. 
It does not fully support the three-level hierarchy view of 
ANSI 13 SPARC, specifically the external schema. It is 
capable of handling large amounts of data. There are a 
number of versions of TOTAL which are supported, i.e. Basic, 
Extended, Central, and Multithread. The Extended and 
Central versions do not have fully re-entrant code, thus 
making the systems a bit. slow in a multiprogramming environ- 
ment where multiple I/O’s are handled. 

Table VII represents a 1979 Datapro survey of 
proprietary software users and their reaction to TOTAL 
(Ref. 20]. From the table, TOTAL is in general a popular 

DBMS, and could support rhe Coast Guards' requirements. It 
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TABLE VII 

1979 DataPro Survey of TOTAL Users 



Overall satisfaction 

Throughput/ef ficiency 

Ease cf installation 

Ease cf use 

Document atio n 

Vendor technical support 

Training 



Overall satisfaction 

Throughpur/ef ficiency 

Ease of installation 

Ease cf use 

Documentation 

Vender technical support 

Training 



! Scale Systems: 
Excellent Good 


Fair 


Poor 


W. A. 


30 


51 


5 


1 


3.3 


20 


48 


17 


2 


3.0 


26 


41 


17 


3 


3.0 


25 


50 


12 


0 


3.2 


14 


41 


27 


5 


2.7 


18 


36 


26 


7 


2.8 


10 


38 


22 


10 


2.6 


imputer Sysrems: 
Excellent Good 


Fair 


Poor 


W. A. 


12 


1 9 


4 


0 


3.2 


1 


27 


7 


0 


2.8 


14 


17 


4 


0 


3.3 


10 


16 


9 


0 . 


3.0 


5 


17 


10 


3 


2.7 


10 


14 


8 


3 


2.9 


6 


16 


8 


3 


2.8 



is worthy to no x e that TOTAL runs 
e.g. Prime 350- "50, PDP-11, VAX-11, 



on many minicomputers, 
and others. 



E. HIERARCHICAL - SYSTEM 2000/80 

System 2000/80 supports a number of computer systems and 
operating environments, and handles hierarchical tree data 
base structures. The system was first introduced by MRI 
Sysrems Corporation in 1970. In 1979, MRI was acquired by 
Intel Corporation. An interesting feature is that Intel 
provides a Data Ease Assist Processor (DBAP) which incorpo- 
rates the Intel semi-conductor disk unit with the System 
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2000/80 database management system. This is a variation of 
the database machine mentioned in Chapter IV. 

1 . Cap ab ili tie s /Ch arac teristi cs 

An Integrated Data Dictionary (IDD) supports System 
2000/80 vis-a-vis maintaining information about the 

processing environment. An English- like query language, 
QUEST, is provided tc generate reports, and a report writer 
is available fcr sophisticated batch report generation 
requirements. A Programming Language Extension (PLSX) 
allows commands to be embedded in host programming languages 
like FORTRAN, COBOL, PL/I, and Assembly Language; this 
allows further processing of data from the data base. 

System 2 C00/80 supports both batch and interactive 
processing. Also journaling, rollback, recovery, and 
security are standard features of the DBMS. Security is 

provided for at the data base, record, or item level by 

restricting accesses to update, retrieval, or search. 

Finally, sixty-three command streams can be handled concur- 
rently and interleaved at the I/O level. 

2 . Critique 

System 2C00/80 runs on many machines and environ- 
ments including IBM 360, 370, 303x, and 4300 series; Univac 
1100 series; and CDC 6000/Cyber Series. 3oolean logic capa- 
bilities make it amenable to ad-hoc queries. The biggest 
drawback is that it is not available on minicomputers and if 

requires 180K bytes cr more of main memory. The results of 

a DataPrc survey [Ref. 20: d. 70E-526-01b] are provided in 

Table VIII. In general. System 2000/80 can support Coast 
Guard's requirements, except for the minicomputer 
requirement . 
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TABLE VIII 

DataPro Survey of System 2000/80 Users 





Excellent 


Good 


Fair 


Poor 


W. A. 


Overall satisfaction 


12 


15 


3 


0 


3.3 


Th roughput/e f ficr ency 


3 


16 


1 1 


0 


2.7 


Ease of installation 


5 


1 1 


7 


0 


2.9 


Ease of use 


11 


13 


6 


0 


3.2 


Documentation 


6 


15 


8 


1 


2.9 


Vendor technical support 


9 


15 


3 


0 


3.2 


Training 


1 1 


14 


0 


0 


3.4 



F. SUMMARY 

In general any BEMS from one of the three data models 
can support the Coast Guard's requirements. These require- 
ments are detailed in Chapr.er VI. The drawback of the 
hierarchical data model implementation is their memory 
requirements. IBM's IMS (IBM's hierarchical DBMS), and 
Intel's System 2000/80, mentioned previously, cannot be 
implemented on minicomputers. Ease of use is somewhat 
limited because, once the conceptual schema is defined, it 
becomes very difficult to modify. Also, the conceptual 
schema must be manv-to-one and there are many applications 
which do not fit this mold. On the positive side, the hier- 
archical data model effectively supports very large 
centralized data bases, where efficient implementation is 
the constraining factor. This data model also, has been 
used for a decade in both industry and government with some 
success; hence there is a let of knowledge about its use and 
implementation. 
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The network data nodal, unlike the hierarchical data 
model, can be implemented on minicomputers. The network 
data mocel does support large data bases efficiently. This 
model too, has teen in existence for better than a decade. 
The problem for an unsophisticated user is the implementa- 
tion details that must be known to use the DBMS. Access 
paths and the physical data organization must be defined 
prior to use by the implementor. Although the data model 
supports many-to-many relationships of data, it is done only 
with difficulty. 

The relational data model is relatively new and based 
upon the theoretical papers of Dr. Codd. There are r.ot many 
commercially available relational DBMSs in existence today. 
Because cf this, what is known about the relational model is 
restricted to the research laboratories and the academic 
environment. The relational models that do exist support 

small and medium sized data bases. The exceptions are 
ORACLE, INGRES, and SQL/DS. Implementation of large data 
bases are usually plagued with performance problems. On the 
positive side, the relational models are easy to use, i.e. 
the conceptual and external schemas can be modified easily 
to fit any situation. This makes it ideal for supporting 
Decision Support Systems (D SS) . Undoubtedly, the relational 
model will play a more and more important role in the 
future. First, more will become known about them as they 
are implemented commercially. Secondly, most of the 
research at universities and RSD centers are concentrating 
almost exclusively on the relational model. 
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71. DATABASE MANAGEMENT SYSTEM STRATEGY 
A. GENERAL 

This chapter will present a broad strategic plan for the 
Coast Guard’s use and implementation of a database manage- 
ment system (DBMS). To help motivate this scenario, the 
Coast Guard's present situation is outlined followed by a 
short discussion of their planned growth in the database 
technology arena. Items such as goals, database management 
system reguirements, data dictionaries, migration paths, and 
approaches are discussed. It is the authors’ belief tha^ 
for the implementation of any strategy the Coast Guard 
employs, the technology must be commercially available and 
have proven itself ever the past few years. The Coast Guard 
can ill afford to tackle some of the state-of-the-art tech- 
nology with its meager resources. However, the actions 
taken today will have an impact on ^he Coast Guard's ability 
to use new -echnclogv later when it becomes available on the 
market. A wrong decision today could effectively lock the 
Coast Guard out of very promising alternatives in the future 
years. What follows are the authors opinions about how to 
achieve a database management system technology today in the 
Coast Guard without locking the Coast Guard out of the 
changing technolcgy. 

1 . Present Sit uation 

ft 

All strategies must begin with an inventory and 
evaluation of the present situation. Clearly the Coast 
Guard is behind the proverbial 'eight ball' in the ADP envi- 
ronment. Even with the Commandant's attention and 
reorganization cf Coast Guard Headquarters to provide a 
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flag-rank office to oversee and direct Coast Guard-wide 
information requirements, there is still a long way to go. 

To date the Coast Guard’s use of DBMSs has been 
rather haphazard. A few years ago the Coast Guard bought 
Cullinar.e's database management system, IDMS, for Coast 
Guard-wide use. Because there were no Coast Guard users, 
IDMS was turned over to the Department of Transportation's 
Computer Center (TCC) . Today, if the Coast Guard would like 
to use it, they have to pay a surcharge for both the use of 
the DBMS and the TCC's computer. Most applications in use 
today are using file structures that were popular in the 
late 1960's and early 1970' s, and are not taking advantage 
of current database management technology. Probably the 
most representative example is the Standardized Aids to 
Navigation Data System (SANDS) [Ref. 5], The system was 
developed in the late 1960 's using the file structures of 
that date, i.e. flat, fixed, sequential access record struc- 
tures. As a result, today the system is of little use or 
benefit as the data cannot be changed to meet the require- 
ments of the users. As an aside, SANDS is being revised to 
see if the data, collected over the past 15 or so years, can 
be of any benefit. The one bright spot in this picture is 
the development of the Marine Safety Information System 
(MS IS ) . Although if has taken over ten years to get to its 
present state, and it is net fully implemented; database 
management technology plays a pivotal role in its develop- 
ment and implementation. MSIS uses Cincom's DBMS, TOTAL. 
The use of a data dictionary allows control of over 2500 
data elements throughout the system. Also, Civil 
Engineering (G-ECV) is currently developing a data base, 
data dictionary, and da^a directory using database 

technology [Ref. 5; p. 5-32 ]. 
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2 • P lann ed Gro wt h 

Headquarter's Offices are planning new systems- at a 
phenomenal rate. A glance through Commandant's Instruction 
M5230.81, Automated Data Processing (ADP) Plan, provides the 
interested reader with the size and scope of the new 
efforts . 

The most ambitious new undertaking is the 'District 
Minicomputer Project.' It is the indention of the Commandant 
to procure minicomputers and place them in each of the 
twelve District Offices to provide an expanded ADP capa- 
bility at major field commands. This project is to be 

incrsmertly developed with initial atrention being focused 
on identifying and responding to the critical information 
and management needs of the District Offices. Phase one of 
the project is to perform the required planning, identify 
information needs, conduct a feasibility study and provide 
for resource decisions. Phase two provides for the develop- 
ment of specifications and standards. Phase three initiates 
procurement action, performs system development, conducts 
database formulation and test/integration. Finally, phase 
four commits the system to operation and provides for 
refinement and expansion. This project is receiving top 
management control from the Office of Command Control and 
Communication (G-T) with the attendant bureaucract ic control 
and standardization. 

Cnee it is fully operational, the Marine Safety 
Information System (MSIS) will provide the Coast Guard with 
its first fully matured Management Information System. The 
Operational Computer Center (OCC) located at Governors 
Island, New York, using PRIME 750s, besides running the 
Automated Mutual-Assistance Vessel Rescue System (AMVER) , 
the Computer- Ass isted Search Planning System (CASP) , Ice 
Plot (ICIPLCT) , and the Enforcement of Laws and Treaties 
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(ELT) database (limited), will support 
Computer System (HACS), the Spill 
Inventory System (SKIM) , and the ELT 
Thus Coast Guard’s near term future re 
than double today's present capacity, 
number of progra as and files necessary 
mation needs for the rest of the decade 



the Hazard Assessment 
Cleanup Equipment 
database (expanded) . 
quirements will more 
while quadrupling the 
to support the infor- 



B. DBMS OBJECTIVES 

A database management system must address the basic 
issues of (1) the organization of an intearated database. 



(2) the storage locations for 
location of data in the svstem, 
rent addresses, and (5) the 
provide security and in+egrity. 
ware, other appendages are co 
dictionary, and cood software f 
maintaining, and generating 
These ~wc items will be disc 
What follows is a discussion 
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' UN D2 RW A Y_H CU RS 1 from the database OPERATIONS along with 
' ST AN EARE_UNDER W AY_ HOURS ' , and ' AVAIL A BLE_VESSELS ' to deter- 
mine deployment schedules. The DBMS must be able to support 
both views of this single data element. Therefore the DBMS 
must be able to derive from both the data and logical rela- 
tionship, the logical files that are necessary. Further, 
the programmer should not have to be concerned with how the 
data is physically shared. Transparency for the programmer 
is the main concern. 

2. Per forma rce 

The Coast Guard will have requirements for both 
interactive and batch processing via the DBMS. The more 
complex queries and reports will, in all likelihood, be 
submitted for batch processing, while the relatively simple 
ad-hoc query will be submitted interactively. Wilson-Hill 's 
Report, [Ref. 10: p. 4-15], indicates that approximately 90% 
of Coast Guard's use will be interactive. It is not unrea- 
sonable that other systems will have a similar mix; however, 
they will probably nor be as high for interactive 
processing. Hence, database applications designed for use 
by a terminal operator, and queries of the data base, must 
have a response time appropriate for man-machine dialogue, 
i.e. response times of 3 to 5 seconds 85% to 90% of the 
time. [ Ref. 21 ] 

In addition, the DBMS must be capable of handling 
the throughput. Initially, in any DBMS whether for the 
District Minicomputer Project, for the Operational Computer 
Center (CCC) , or for one of the 'super' minicomputers at 
Coast Guard Headquarters, the throughput will be relatively 
low. As a minimum each 'super' minicomputer should be 
capable of supporting 150 users with 20 concurrent users. 
Since these are the requirements determined and supported in 
Wilson-Hill 's Report, [Ref. 10: p. 4-17], it seems 
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appropriate that this be a basic requirement for any DBMS 
used by Coast Guard. Needless to say, if an application or 
subject area data base requires higher performance then that 
should be the level. The Marine Safety Information System 
(MSIS) is one such exception. This system provides the 
upper end cf performance throughput, as their requirements 
are fcr ever 250 users with up to 50 concurrent users. 

3* minimization of Costs 

There are many cost features which interact when 
considering a DBMS. The first is the cost cf the DBMS soft- 
ware itself. Depending on the features in the DBMS, the 
costs may be rather significant, i.e. $100,000 or better for 
its purchase, plus a monthly maintenance charge as a DBMS 
software package is usually proprietary property. The ether 
consideration is that the purchase price may only be for one 
copy, i.e. for the District Minicomputer Project - 12 copies 
may have to be purchased. 

The largest cost, the one usually overlooked or 
underestimated, is the database conversion, loading, and 
establishment of a data dictionary system. There is the 
cost of loading say a ’flat’ COBOL file into the data base. 
Also there is a cost incurred of not converting or loading 
COBOL files into a CEMS. For instance, if data cannot be 
converted or loaded into a data base, then the information 
is lost. Therefore, the Ccasr Guard has a decision to make 
whether or not to maintain the old procedures for 
capturing, storing, and manipulating this data or cut with 
the past and start anew. This maintaining of old ways is 
costly in programmer maintenance and data entry effort. As 
such, this decision should be considered carefully. 
Installing a data dictionary system is not an easy task, and 
the cost is usually in terms of politics. Individuals 
consider data to be their own property and not a corporate 
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entity to be managed as such. The cost is the effort it 
will take to integrate the data dictionary system into the 
organization. 

These short term costs must be balanced against the 
long term costs of creating additional files, changing 
logical structures fcr different programmers or applica- 
tions, and the overhead required for data searching and 
storage capacity. Without a DBMS, maintenance programming 
becomes prohibitively expensive in just a short time. 
Changes to data structures or logical programs cannot be 
done without ma"or disruption to other pregrams and data. 
There comes a time where one scarifices performance require- 
ments in order to accommodate new requirements in the 
application. In the case of reduced requirements, time may 
have to be degraded as the volume of data tc be retrieved or 
updated reaches the upper limit of the capability of a DBMS. 

4 . Minimal Eeaundan cy 

The importance of this requirement cannot be over 
emphasized. It is at the core of what database management 
systems are all about. 

A data base may be defined as a collection of interre- 
lated data stored together without harmful or 

unnecessary redundancy to serve one or more applications 
in an optimal fashion; the data are stored so that they 
are independent of proara ms which use the data; a common 
and controlled approach is used in addressing new data 
and in modifying and retrieving existing data within the 
data base. One system is said to conrain a collection 
of data bases if they are entirely separate in 

structure. [Bef. 22] 

There are three reasons fcr keeping data redundancy to a 
minimum. First, there is the additional cost: of storing 

extra data. At one time this was extremely important, but 
today with the cost per bit of stored data dropping so 
rapidly it is becoming less of an issue. The second reason 
is the requirement tc update all the different copies of the 
data. As a result of duplicate data, computer overhead 
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increases, and the complexity of the software to keep rrack 
cf the duplicate data and the access paths increases. The 
third, and probably rhe reason most managers distrust 
computers, is that different copies of the data are in 
different update states. These different update states 
produce inco nsista r.t information depending on the access 
path taken by the DBMS. However, if is important to realize 
that a certain amount of redundancy may be necessary to 
improve performance. This is even mors so in a distributed 
type environment than in the traditional centralized method. 
In cases where redundancy or controlled redundancy is 
required steps must be taken to insure concurrency control 
or synchronization of these redundant data items. 

5 * £uer_y ana Re p ort Ge ne ra tion 

The DBMS should provide facilities to respond to 

requests that are net anticipated in any degree of detail - 

i.e. ad-hoc queries. Since Coast Guard personnel will vary 

* 

in degree of computer sophistication, it is necessary "'hat 
the DBMS provide a query or retrieval language that is 
•English-like* and relatively easy to use. As an aside, the 
reasons DBMSs have caught cn so well, is their ability to 
extend the power of the 'bare' machine. It allows both a 
programmer and non-programmer the ability to manipulate data 
without having tc worry about things like; how is the data 
stored, what is the access path, is the file indirect 
sequential or the other many details which do not help the 
user with his immediate immediate task. 

The types of queries can range from very simple to 
relatively complex. As a minimum, the query must be able to 
access data in the database through a variety of methods, 
including direct and Boolean (logical) connectors. If must 
be capable of interfacing with other system capabilities 
like application programs and report generators. As a 
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further requirement it must be able to generate a query 
aqainst temporary files and support several users 
concurrently. 

The report generatcr must be flexible enough to 
support a variety cf output formats, and interface with 
application programs. The language should be easy to use 
(English-like) , logical, and should be able to process 
single and multiple files with the capability to build and 
store output for later use. 

There exists commercial report generators like FOCUS 
and RAMIS II which car. be procured as an add-on item, if not 
available with the DBMS software. 

6. Integrit v Controls 

The DBMS system must provide routines to insure that 
the data in the database are accurate at all times. One can 
view maintaining the integrity of a database as protecting 
the data against invalid (not illegal) alteration or 
destr uc* ion. 

First, the system must be capable of checking each 
individual data item value for plausibility, e.g. the hours 
a vessel is underway during the week cannot exceed 168. In 
a multi-user system the loss of an update must be guarded 
against. This can happen when data are shared, and one 
update is allowed to overwrite the other, thus nullifying 
the first update. (Note: In some systems, allowing several 

users to update the same data concurrently is a requirement. 
An airlines reservation system where it is important net to 
book a seat more than once, is the classic example.) 

In general, loss of integrity will arise as a result 
of a hardware or software failure such as at a central 
processor, data channel, o r an inpu -1- /output device. Human 
error on the part of the terminal user, programming errors 
in the underlying operating system, or programming errors in 
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the database application will also adversely affect the 
integrity of the data base. 

Several routines should be provided to support 
system integrity such as, journaling routines, dump rout- 
ines, recovery routines, backout routines, 

checkpoint/restart routines, and detection routines. 
Journal routines record every operation on the database in a 
systems log or audit trail. As a minimum the audit trail 
should contain an identification of the transaction 
concerned, a timestamp, an identification of the terminal 
and user concerned, the full text of the input message, and 
the type of charge and the address of the data changed, 
together with its before and after values. Dump routines 
are used to make backup copies of the database; usually only 
selected portions of the database are dumped. Recovery 
routines are required to restore the database to an earlier 
state if there is a hardware cr software failure. The audit 
tape will be used as input to this routine. Detection rout- 
ines will be required to search for any violations of 
integrity contraints before the database is written on. 

7 • Sec urit y and Pri vac y 

The Coast Guard has a requirement for both security 
and privacy cf data. Information will eventually contain 
classified data and confidential personnel information. 

Data security refers to protection of data against 
accidental or intentional disclosure to unauthorized 
persons, or unauthorized modifications or destruction. 

Privacy refers to the rrght of individuals and organ- 
izations to determine for themselves when, how, and to 
what extent information about them is to be transmitted 
to ethers. [Ref. 23] 

The DEMS must be capable cf positively identifying users 
(authentication) before they are allowed to use the DBMS. 
The software must provide access control *o insure ordered 
accesses are valid. Transactions must be capable of being 
monitored, and data must be reconstructible from journals. 
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8 . 



Thr se-Le vel Hierarchy 



In the previous chapter there was a reference to the 
American National Standards Institute ANSI X3 SPARC study 
group's interim report regarding the three-level hierarchy 
view of a DBMS. A DEMS must support this conceptual view of 
a database, i.e. internal schema - (physical view) , concep- 
tual schema - (logical view) , and external schema 
(programmer's view) . Each schema should be independent from 
the other schemas; in other words: 

1. The programmer utilizing the external schema should 
be provided (by the conceptual schema) all the infor- 
mation required to use the external schema and 
nothing mor e. 

2. The data base administrator utilizincr the conceptual 
schema should be provided (bv both the external 
schema and the internal schema) all the information 
required to logically design the database and no thin g 
mor e. 

3. The implementor of the internal schema should be 
provided (by the conceptual schema) all the informa- 
tion required to complete the implementation of the 
internal schema and nothing m ore . ~ 

This type of construction in the DBMS provides flexibility, 
and ensures maintainability and reliability. Flexibility is 
provided because changes in the size of the data base, 
storage of the data base, and ' the number of users, can be 
accommodated up to the limits of the technology imposed upon 
the system i.e. memory size, speed of CPD, etc. The entire 
DBMS should be more maintainable as those items that are 
likely to change, e.g. the storage structure, corporate view 
of the data and programmer use of data, are isolated from 
one another. Hence, changes are not propogated throughout 
the entire system. Because the entire DBMS is more maintai- 
nable, the reliability should follow as a natural 
consequence. 
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C. CCAST GUARD INFORMATIONAL GOALS 



Today the Coast Guard is not facing the complex problems 
cf ether organizations who have many years of data 
processing experience and who have continuously used the 
stat e-cf-the-ar t technology over a long period of time. 
Easically the Coast Guard is just beginning to use some of 
the newer technology available today - database management 
systems, networks i. e. TELENET, 16-bi- 1 : microcomputers, etc. 
This lack of experience is a handicap; it provides a very 
small knowledge base upon which to draw experienced 
personnel. On the other hand, the Coast Guard can learn 
from the organizations that have already introduced the new 
technology, like DBMSs and distributed processing. The 
first thing that is discernible from organizations that have 
implemented database technology, is that the requirements 
for a DEMS are easily met by many of the commercially, avai- 
lable packages. This is not particularly surprising, 
especially as the requirements, although difficult to imple- 
ment, provide handsome returns in the market sector of 
society. The two most acute problems stem from managerial 
decisions. One concerns the implementation of database 
management technology, while the other, concerns the poli- 
cies to keep current with computer technology. First, an 
organization will invest a great deal of resources, devel- 
oping applications using COBOL type files. The organization 
finds out later, they cannot take advantage of new tech- 
nology, e.g. DBM 5. The reason is there is no ec on omi cal way 
to convert the data and procedures of the COBOL oriented 
system no a DBMS. The second problem affects the federal 
government probably more than the private sector. This is 
concerned with the upward compatibility of resources, i.e. 
computers, operating systems, DBMSs, and secondary storage 
devices. Management invests heavily in current computer 
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technology only ending up having to scrap the previous 
effort to take advantage of the newer technology. Today, 
management is no longer allowing this to happen. The mark- 
eting strategies of the computer industry recognize this 
fact, and now provides for upward compatibility of new 
items. An exception is the microcomputer industry. Thus, 
the problem reduces to determining a migration path for 
expanded computer system requirements. Therefore the goals 
of a DBMS strategy are: 

1. To provide for the protection of the organization's 
intellectual development and 

2. To provide a migration path for expanded 

requirement s. 

What is of concern in regards to goals is the ability to not 
only integrate database management technology within the 
organization, but to insure its future and to reduce the 
turbulence that comes from follow-on changes. 

1 . Pro tect ! cn cf Inte l lect ual Development 



Most entities utilize a DBMS because it provides 
easier access to data while allowing the programmer to spend 
his time writing programs tc manipulate that data. Although 
this is a very desirable feature of DBMSs, it is not the 

main concern. In fact, because DBMSs have abstracted the 

data so that it is closer tc the way people think, an enti- 
ty's data base can be allowed to grow willy-nilly. For 

example, an application for law enforcement is determined to 
be extremely valuable for the organization. To help with 
the development of a management information system, the 
designers and implementors decide to use a DBMS to organize 
the data. However, the data going into the data base is 
defined and utilized by only a small fragment of the organi- 
zation even though the data is of benefit to other entities 
within the organization. Without too much trouble, one can 
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The other entities within the 



picture what happens, 
organization develop their own management information 
system, defining data in their own way and using different 
DBMSs. Before long, the organization has a proliferation of 
data with much duplication and inconsistency. But the worst 
thing is that there is no w ay t o protect the data and proce- 
dures that have teen developed when the organization either 
tries to consolidate the redundant data, to reduce bottle- 
necks in Derformance, or to take advantage of new 

technology, like a back-end processor to handle DBMS 
funct ions . 

An obvious solution is to centralize everything and 
have all the organization's data placed into one big corpo- 
rate data base tha + will provide the manager with everything 
there is to know about the organization. Many companies and 
agencies have tried this only to fail. It is just too big 
an undertaking for most large organizations. An approach 
taken from software engineering is to modularize the process 
and take advantage of what the DBMS software provides. 
First, try to minimize the effects of change. For example 
where the data bases are developed by application, a change 
in a da A a element resulting from a law or regulation will 
have a ripple effect throughout the organization. However, 
if data bases are developed by subject area the effects of 
change are reduced. Therefore, one way to help insure 
protection of an organization's intellectual development is 
to develop data bases by subject area versus application 
areas . 

To help implement, subject area data bases, and main- 
tain consistency throughout the organization, the use of a 
data dictionary system is essential. If the Coast Guard 
requires a three-level hierarchy for a DBMS in each subject 
area then, surely at the conceptual schema level, one must 
know what the entities and characteristics of those entities 
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are that one is managing. For one person tc manage 500 or 
more data elements without some kind of software tools is 
unthinkable. This is a conservative estimate of the number 
of data elements that will comprise a subject area data base 
[Ref. 10: p. 3-4]. In short what a data dictionary system 
provides is the capability for: 



1. Specifying the type of an entity, such as a form, a 
data element, or a computer file. 

2. Oniguely naming an entity and describing it in appro- 
priate terms, such as the range of values of a data 
element or a narrative description of its meaning. 

3. Specifying the flow and the storaae locations of data 
entities within the organization or within the 
computer installation. 

4. Specifying associations and relationships among the 
data entities; for example, appearance on the same 
form, or derivation of an entity from another. 

5. Specifying and producing reports about the data 
dictionary content., such as a listing of all data 
elements or a cross-reference listing of all 
entities. [Ref. 24] 

The authors believe that the use of a da^a dictionary must 
be a reguirement and the burden a user must pay in order to 
obtain the benefits cf a DBMS. 

In conjurcticn with a data dictionary system there 
exists the requirement for a database administrator. The 
design cf the conceptual schema will normally be done by the 
database administrator and a staff. Also this person will 
be responsible for the implementation of the conceptual 
schema as a physical data base. Once implemented the data- 
base administrat cr performs these functions: 



1. The creation of subschemas for external views. 

2. The grantinc of authorization to use the data base or 
certain parts of it. 

3. Modification of the conceptual schema should the 
original design prove faulty or the requirements of 
the organization change. 

4. Modification cf th§ implementation of the conceptual 
schema by tie physical schema. should past usage of 
the data base indicate another organization or the 
data base be more efficient. 
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5. Making backup copies cf the data base and repairing 

damage (e.g. 'trashed pointers') to the data base. 

[Ref. 25] 

One should not underestimate the difficulty of this task. 
Defining a conceptual schema to accommodate the external 
views of multiple users is no easy task. In fact, most 
personnel hired as database administrators leave out of 
frustration. Ore cannot expect this position to be filled 
by a junior person within the organization. The position 
requires the talents cf a project manager. He must have the 
respect cf the organization, and a fairly in-depth technical 
background in computer science. Although this is an impor- 
tant job, -raditionally , it has been either underestimated 
in its importance, or ignored. In either case, the effec- 
tive use of database management technology has been minimal. 
The Coast Guard must be willing to establish this position 
and fill it with highly qualified personnel at those offices 
utilizing database management technology. 

While the development of data bases by subject area, 
and the use of data dictionary systems will help provide 
seme continuity, it will not insure a high degree of protec- 
tion of developed data bases. If those data bases are 
allowed the choice cf selecting DBMSs without any overall 
central policy, then the efforts of integrating a data 
dictionary and data base administrator, will fail. Because 
the policy and selection cf equipment for the District 
Minicomputer Project, is a Headquarters controlled under- 
taking, they will help insure the protection of the 

intellectual development of data bases at different District 
Offices. Because the District Offices are somewhat indepen- 
dent, responsible tc Program Managers at the Headquarters 
level and responsible for field units in the District's 
jurisdiction, there is now little need to distribute data- 
base management systems among the different districts. In 
fact there is little need at the present time to distribute 
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the data between Districts . Although the distribution of 
data may be desirable in some cases, the communication 
costs, protocols, control, and lack of technically know- 
ledgeable personnel make this a high risk undertaking at the 
present time. The risks of trying to distribute both the 
data and the processing among districts at the present time 
outweigh any of the benefits. However, at a later time when 
the distribution of processing and data are deemed desi- 
rable, then it may be accomplished without wholesale 
disruption of past efforts . This can happen only if the 
Districts are required to use predetermined data bases, 
based upcn subject areas, and if the Districts are required 
to use the same commercially available DBMS package. 
Therefore, the control of the selection of DBMSs and the 
broad definition of subject area data bases should be a 
Headquarters level function. It is important to note that 
development, implementation, and use of data bases is a 
decentralized function, i.e. the responsibility of the 
District Office cr the Program Manager. 

2 . Gro w t h 

There are two fundamental facts about data 
processing, change and growth. Costs are dropping, machine 
structures are changing, new architectures are appearing. 
What the Coast Guard thinks its requirements are today, and 
the technology to handle those requirements, will not be 
sufficient tomorrow. The Coast Guard will need to move to 
new systems because they are more cost-effective; however, 
the Coast Guard cannot re-write the multitude of old 
programs because there will not be enough programmers. The 
computer industry itself has recognized these two facts for 
years. They realize they cannot design, manufacture, and 
market equipment so that it stays continuously current. The 
manufacturers have developed a strategy to allow for both 
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change and growth. Both operating systems and the 'bare' 
machine (processcr) on which the operating system runs are 
developed using the manufacturer's strategy for handling 
change and growth. An initial version of an operating 
system will be released, and as new technology is added, 
newer versions of the operating system are available. This 
usually happens without major disruption to the utilities 
and applications utilizing the operating system. (Of course 
this is not true if an organization has modified the oper- 
ating system.) Hardware is also planned to be upwardly 
compatible. Prime Computer, Inc.'s 50 series is an example 
of a compatible hardware family. With this marketing stra- 

tegy, an organization can move up to a more powerful 
processcr without major re-writes or disruptions. The 
computer manufacturers, in short, plan long-range migration 
paths for their customers. Some examples are the facilities 
in a new operating system may lead the way to future hard- 
ware change, or a software architecture is planned to 
accommodate future machines. Therefore, the Coast Guard 
must adopt a similar strategy. 

The initial environment the Coast Guard will be 
dealing with is a stand-alone, large minicomputer including 
the operating system, utilities such as compilers, sort 
routines, etc, and DBMS software. For discussion purposes, 
if is assumed there is a front-end processor to handle the 
terminal commun icat icn protocols. In the District Offices, 
compatible machines will reside with compatible software. 
This cannot be an assumption with regards to the other 
computer systems* within the Coast Guard. For example, the 
Operational Computer Cenrer (OCC) uses Prime 750s, while a 
Headquarter's Office may be use a VAX-11/780. There are 
three migration paths available. The first is a migration 
up to larger processors, the second is creation of a network 
of minicomputers, and the third is use of a smaller minicom- 
puter as a back-end database machine. 
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more 



If the path chosen were migration ~c a larger, 
powerful processor, then a requirement for not having to 
re-write, the application programs and library routines, 
would most certainly be mandatory. To avoid this re-writing 
evolution, one trust have compatibility of hardware, oper- 
ating system, and DEMS software. Incompatibility in or 
among any of these features will require some re-writes. 
Maintaining the compatibility of hardware and operating 
systems is a slim possibility in a federal agency because of 
the procurement restrictions of the Brook's Act. Providing 
for a competitive procurement and requiring compatible hard- 
ware, operating system, and DBMS software is a task with 
little chance of success. If this migration path were 
chosen, the Coast Guard should be prepared to do some 
re-writes of the application programs, and in some cases 
'major' re-writes. 

The second option is to create a network of minicom- 
puters, where the procurement of a new minicomputer 
represents a new node in a new network structure. Certainly 
this will increase the 'computing power' of the system, but 
new problems are introduced with this approach. If the 
configuration is to have both processors access the same 
data, then linking the two processors together, and 
providing for synchronization of reads and writes will be 
required. At the present time this is not a common approach 
and the experience base is not large. It is the author's 
understanding that Battelle Labs of Columbus, Ohio, who are 
developing the Marine Safety Information System (MSIS) , are 
proposing an architecture similar to this. The experience 
they are gaining in this effort of linking several Prime 750 
computers together should be very valuable. Another 
approach within this option is the creation of a network of 
minicomputers by adding another layer of software - the 
network operating system. This is similar to IBM's System 
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Network Structure (SNA) which allows many processors to be 
hooked toqether. The problem here is that the addition of 
the network operating system and another processor may not 
relieve the burden of the DBMS functions on the first 
machine. Also a number of these networks like SNA support 
only the manufacturers equipment. Thus the Coast Guard must 
again contend with the Brook's Act in the procurement arena. 

The third option is the use of a back-end database 
machine. As discussed in Chapter IV, this is an emerging 
technology where one is truly working within the state-of- 
the-art. The advantages of a back-end database machine is 
its ability to handle a heterogeneous environment easier 
than the ether two approaches. However, loading of the data 
from the host to the back-end may be extremely difficult if 
the hosx say supports a CODASYL approach and the database 
machine supports a relational approach. This migration path 
at present is the most expensive and difficult to achieve of 
the three, and the percent usage of the host to DBMS func- 
tions will determine if this migration path is even 
cost-effective. 

In summary cpxion one, migration to a larger 
processor, is easiest to implement, and there is more know- 
ledge and experience about this migration path than any 
other. The second solution is harder than the first, and 
the database machine is possibly the hardest because it is 
current state-of-the-art and there does net seem to be much 
experience to date with this alternative. 

D. HETEROGENEOUS VERSUS HOMOGENEOUS SYSTEMS 

Distributed database technology requires a hard look at 
the problems one encounters when examining heterogeneous 
systems - heterogeneous systems are interconnet ed proces- 
sors, software, and data structures that are dissimilar. 
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There are three (3) main problems when dealing with hetero- 
geneous systems at the database management level. First, 
different types cf database software are incompatible (even 
without considering distributed databases) . Second, file 
structures are expensive to convert to other file structures 
or database structures. Finally, even if all the software 
is compatible, problems may arise from incompatible data 
fields and data structures due to inadequate data adminis- 
tration in an organization. Although there is at present 
little need to distribute data bases in the Coast Guard, 
later efforts to do sc will be inhibited, if there is not an 
early commitment to database technology which requires the 
data bases in an organization to be compatible. Therefore, 
the emphasis should be on developing homogeneous systems - 
homogeneous systems are interconnected processors, software, 
and data structures that are similar. 

One realizes that the Coast Guard survives in an envi- 
ronment of regulations that strongly discourages the 
development of homogeneous systems. The Federal Procurement 
Regulations requiring procurements to be comperiti vely bid 
is one such regulation. There are some exceptions to this 
rule, but they are such that the Coast Guard cannot in 
general apply these exceptions. The approach taken by the 
District Minicomputer Project is one solution to providing 
for a high degree of compatibity. A similar effort must be 
undertaken at the Headquarters level if one expects to 
distribute data bases to meet higher goals. At the present 
time, the cost and degree of technological sophistication is 
more than the Coast Guard can handle in distributing hetero- 
geneous systems. Therefore, emphasis should be placed on 
developing homogeneous systems, not on trying to distribute 
present-day heterogeneous systems. 
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E. SUMMARY 



The Coast Guard is ccram mitred to investing in the archi- 
tecture of the future today, so that the Coast Guard may 
become an 'information corporation' of the 1990 's. The 
consequence of this is an exponential growth in computer 
systems over the next few years. An important aspect of 
these computer systems will be database management system 
technology. A Coast Guard DBMS has the following require- 
ments - provide for multiple views of data, provide for 
acceptable performance, minimize cost, minimize redundant 
data items, support query and report generation, provide for 
integrity of the database, provide for both security and 
privacy access control, and support the three-level hier- 
archy. The Ccast Guard must protect its intellectual 
development during this period by developing data bases by 
subject area instead of by application, requiring a data 
dictionary system, and committing itself to provide quali- 
fied database administrators. Orderly growth must be 
determined by a migration path now instead of jusr letting 
it happen. In most cases the simplest solution is to use 
the more advanced technology provided by the original 
vendor; however, the creation of a minicomputer network may 
be feasible as the Ccast Guard gains more experience in the 
computer field. Finally the Coast Guard should strive now 
to develop homogeneous systems instead of trying to distri- 
bute present-day heterogeneous systems. 
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VII. CONCLUSIONS 



The following are the conclusions which the researchers 
have formulated as a result of their thesis research. 

First, the Coast Guard should design its information 
systems for change. The rearchers have discussed the need 
for system designers to be conscious of the effect which 
technological change has had, and will continue to have in 
the computer industry. The Coast Guard does not want to 
lock itself out of any premising technological advances 
which will occur, and it must also recognize the need for 
growth and change in user r eguireraer.ts . Therefore the Coast 
Guard should develop flexible systems which are amendable to 
future change. 

Second, the researchers have pointed out that since the 
Coast Guard is relatively new at procuring information 
systems, the need to have sophisticated computer networks, 
such as 13 M' s SNA, is net warranted at this rime. This 
policy is in accordance with prudent evolution, and leads to 
the conclusion that there will nor be a great deal of data 
sharing reguired among various Coast Guard organizational 
elements initially, alrhough it must be recognized that in 
the future the Coast Guard may need ro create these sophist- 
icated computer networks (or distributed systems). In order 
to support future networking possibilities, ir is recom- 
mended that the Coast Guard strive for homogeneous systems 
as much as possible so that this interconnect ion is much 
easier *c accomplish. The Coast Guard's scarce resources 
dicrate that connecting heterogeneous systems be postponed 
at this time, and its efferrs directed toward the develop- 
ment of homogenous systems. 
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Third, the authors have concluded that the Coast Guard 
should require good documentation of all of the systems 
which are developed and installed. Being a military organi- 
zation implies c great deal of personnel rotation, and 
therefore in order that new personnel coming aboard under- 
stand, operate, and maintain the system, good documentation 
is essential becuase there probably won't be anyone around 
who was present at installation after a few years. 

Fourth, the researchers have concluded that the Coast. 
Guard should stress the importance of human needs in the 
systems which it develops and acquires. By this the 
researchers are pointing to the need for systems to be easy 
to learn as well as easy to use in order that personnel be 
more compelled to use the systems to assist in their job 
activities, and thereby the system be more responsive to 
user requirements. Other human factors which should be 
considered by the Coast Guard include training and education 
and involving erd users in the design and development of 
syste ms . 

Fif+h, the authors have concluded and recommend that the 
Coast Guard should establish database administrator posi- 
tions throughout the organization, and it should seek to 
fill those positions with talented professionals. The 
duties of the database administrator and staff have been 
discussed in previous chapters, and the researchers consider 
that this position is vital to the success of the proper 
management cf any organization's data base(s). 

Sixth, a key tool which the database administrator 
should have is a data dictionary. The data dictionary is 
essential to ass :st -in implementing subject area databases, 
to maintain consistency throughout the organization, to 
identify sources and uses of the data resources, and to 
construct standards and procedures for those data resources. 
The data dictionary must be a requirement for the Coast 
Guard tc be successful in implementing database technology. 
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a Coast Guard DBMS should include 



Seventh and finally, 
the following requirements: provide for multiple views of 

data, provide for acceptable performance, minimize cost, 
minimize redundant data items, support query and report 
generation, provide for integrity of the database, provide 
for both security and privacy access control, and support 
the three-level hierarchy. 
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APPENDIX A 
RE SOURCES 



I. Personnel Resources. These are approximate figures, subject to change. 



a. Headquarters 


(does 


not reflect 


interim reassignments ) 




CO 


WO 


ENL 


CIV 


TOT 


G-T 


2 


0 


1 


2 


5 


G-TEE 


41 


13 


9 


28 


91 


G-T1S 


7 


0 


4 


42 


53 


G-TTM 


9 


4 


22 


13 


48 


G-TFP 


6 


0 


6 


1 


13 


G-TNR 


6 


0 


8 


0 


14 


TOTAL 


71 


17 


50 


86 


224 



i. District Offices: 

Dist otm 

CO WD EN CV TOT 


eee 
CO WO 


EM 


CV TOT 


fds 
CO WO 


EN 


CV 


TOT 


irm 
CO WO 


EN 


CV 


TOTAL 

TOT 


1 : 2 


3 


16 


0 


21 


: 3 


3 


10 


5 


21 


: 0 


0 


0 


7 


7 


: 2 


1 


0 


0 


3 : 52 


2 : 1 


1 


10 


0 


12 


: 2 


1 


0 


0 


3 


: 0 


0 


0 


5 


5 


: 2 


1 


0 


0 


3 : 23 


3 : 2 


3 


24 


0 


29 


: 3 


3 


5 


5 


16 


: 0 


0 


1 


10 


11 


: 2 


1 


0 


0 


3 : 59 


5 : 2 


2 


15 


2 


21 


: 2 


3 


1 


4 


10 


: 0 


0 


0 


8 


8 


: 2 


1 


0 


0 


3 : 42 


7 : 2 


2 


17 


0 


21 


: 3 


3 


3 


3 


12 


: 0 


0 


0 


5 


5 


: 2 


1 


0 


0 


3 : 41 


8 : 2 


3 


14 


1 


20 


: 2 


4 


2 


1 


9 


: 0 


0 


0 


5 


5 


: 2 


1 


0 


0 


3 : 37 


9 : 2 


2 


13 


0 


17 


: 2 


'2 


2 


5 


11 


: 0 


0 


0 


6 


6 


: 2 


1 


0 


0 


3 : 37 


11 : 1 


2 


10 


0 


13 


: 2 


2 


1 


3 


8 


: 0 


0 


0 


5 


5 


: 4 


1 


0 


0 


5 : 31 


12 : 2 


2 


17 


1 


22 


: 2 


3 


1 


2 


3 


: 0 


0 


0 


6 


6 


: 2 


1 


0 


0 


3 : 39 


13 : 2 


2 


12 


1 


17 


: 3 


3 


3 


3 


12 


: 0 


0 


0 


6 


6 


: 2. 


1 


0 


0 


3 : 38 


14 : 2 


3 


14 


1 


20 


: 3 


2 


4 


3 


12 


: 0 


0 


0 


6 


6 


: 2 


1 


0 


0 


3 : 41 


17 : 2 


3 


21 


1 


27 


: 5 


4 


4 


1 


14 


: 0 


0 


0 


5 


5 


: 2 


1 


0 


0 


3 : 49 


TOT 22 


28 


183 7 240 


32 33 36 35 


136 


0 


0 


_1 


74 


75 


26 


12 


0 


0 


38 489 



CO 


WO 


ENL 


C IV 


TOTAL 


80 


73 


220 


116 


489 



DISTRICT TOTALS 



106 



c. Area Offices 
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91 110 1475 0 1676 



GRAND TOTAL 290 251 2788 366 3695 
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APPENDIX B 
SDD-1 



INTRODUCTION 

SDD-1 [Ref. 26], was developed by Computer Corporation 
of America and supported by the Defense Advanced Research 
Project Agency of the U. S. Department of Defense. It is a 
system for managing data bases whose storage is distributed 










Figure B. 1 SDD-1 Architecture. 

ever a network of computers. The general configuration of 
SDD-1 is given in Figure B.1 and consists of three virtual 
machines; Transaction Nodule (TM) , Data Nodule (DM) , and a 
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Reliable Network (RELNET) . More about these 'virtual' 
machines later. SDD-1 is based upon relational dara struc- 
tures because complex data operations can be simpler and 
mere precise than when data structures are used which are 
not two-dimensional. It is believed by the creators of 
SDD-1 that this type of architecture is appropriate for 
activities requiring access to a single pool of information 
distributed over a wide geographical area. It permits 
decentralized processing for performance, reliability and 
flexibility of function reasons. 

Users interact with S CD-I in a high level language 
called Datalanguage which is in fact a general purpose 
programming language. The data stored at the nodes of SDD-1 
are portions of a relation which may be either a vertical 
subset composed of specified fields of the relation or a 
horizontal subset defined by one or more expressions e.g. 
Value of Field Id # = WAGB. Figure B.2 represents a 'hori- 
zontal* fragment and Figure B.3 represents a 'vertical' 
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Figure B.2 Horizontal Fragment of a Relation. 

fragment. A fragment is either completely present or 
completely absent at any node (DM) and any fragment may be 
stored redundantly at more than one Data Module (DM). 
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ICE_1A.1 = (Name = GLACIER; Id = WAGB-4) 
ICE 1A. 2 = (Homeport = San Francisco) 
ICE” 1A. 3 = (Status = Ops) 
etc . 



Figure B.2 Vertical Fragment of a Relation. 

The implema r.tat icn of a distributed database system 
presents three fundamental problems; concurrency control, 
distributed query processing, and reliable posting of 
updates. Each cne of these problems can be associated with 
cne of three functions for distributed database technology. 
For example, concurrency control can be associated with the 
functions of database management, likewise distributed query 
processing with management of distributed transactions, and 
reliable posting cf updates with distributed data base 
management system reliability. The authors of SDD-1 have 
placed each one of these problems in a distinct processing 
phase - Read, Execute, and Write. Furthermore, each 

processina phase is contained in one of the 'virtual' 
machines mentioned earlier, i.e. Data Module (DM), 

Transaction Module (TM) , and Reliable Network (RelNET) . The 
functions of the Data Module are to respond to: 
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1 . 
2 . 
3. 
4 . 



EE AC part of the Data Module's data base into a local 
workspace at that Data Module. 

MOVE part of a local workspace from this Data Module 
to another Cata Module. 

data in a local workspace ai the Data 



MANIPULATE 
Module . 

WRITE part cf the local workspace in + c the 
data base stored at the Data Module. [Ref. 



permanent 

>6: p. 5] 



The functions of the Transaction Module plan and control the 
distributed execution of transactions. It performs the 
following tasks. 



1. FRAGMENTATION: The Transaction Module translates 

queries on relations into queries on logical frag- 
ments and decides which instance of stored fragments 
to access. 

2. CONCURRENCY CONTROL: The Transaction Module 

synchronizes the transaction with all other active 
transactions in the system. 

3. ACCESS PLANNING: The Transaction Module compiles the 

transaction into a parallel program, which can be 
executed cooperatively by several Data Modules. 

4. DISTRIBUTED QUERY EXECUTION: The Transaction Module 

coordinates execution of the compiled access plan, 
exploiting parallelism whenever possible. [Refl 26: 
p. 5] 

Lastly, the Reliable Network interconnects the Data Modules 
and Transaction Modules to provide for: 
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GUARANTEED 
ered even 
message is 
are never u 



EELIVERY; allowing messaqes to be deliv- 
if the recipient is down at the time the 
sent, and even if the sender and receiver 
p simultaneously. 



2. TRANSACTION CONTROL: a mechanism for posting updates 

at multiple Data Modules guaranteeing that either all 
Da^a Modules pest the update or none do. 



3. SITE MCNITOEING; to keep 
failed, and to inform sites 

4. NETWORK CLOCK; a virtual 
synchronized at all sites. 

The rest of this appendix will 

tion of how 3DD-1 solves the 

earlier . 



track of which sites have 
impacted by failures. 

clock kept approximately 
[Ref. 26: p.~51 

be concerned with a descrip- 

three problems mentioned 
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solves 



CONCURRENCY CCNTBOL: 



In a centralized database management system concurrency 
problems are handled by simply locking the database until 
the write operation has been completed. This has been the 
approach taken by most implementors of a distributed data- 
base technology; however, locking in a distributed database 
system with a high level cf updates can cause substantial 
performance degradation because there is no activity allowed 
on the data until the update is complete. On a distributed 
system where the data has many copies the performance 
problem becomes even mere severe. 

A system will provide for concurrency control if the 
system can provide for se riali zabili ty. The property of 
ser ializability is that the interleaved operation of the 
system is equivalent to one in which the transactions are 
run to completion, one at a time, serially. Hence serializ- 
ability requires that whenever transactions execute 
concurrently, their effect must be identical to some serial 
(i. e. non-int erl eaved) execution cf those same transactions. 
Two major types of conflicts occur to prevent serializ- 
ability; update conflicts and read conflicts. If 

transactions are grouped into classes based on which Data 
Module executes the transaction and what data the 
Transaction Module uses then potential conflicts between 
classes can be analyzed. This is exactly what is done by 
the data base administrator at design time, and is known as 
conflict analysis. 

With conflict graph analysis the Data Base Administrator 
(DBA) defines transaction classes which are named groups of 
commonly executed transactions. These transactions are 

defined by its r.ame, read-set, write-set and Transaction 
Module at which if runs. Figure 3.4 is an example of an 
update conflict. Through conflict graph analysis four 
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Figure B.4 Conflict Graph. 

different situations nay arise each requiring different 
synchronization protocols. They are; no conflict, updare 
conflict, read conflict with one Data Module, and read 
conflict with more than one Data Module. 

To solve the update conflict the two transactions must 
be synchronized, i.e. one must be run first and the other 
delayed until the first transaction is completed. This 
order of processing transactions is determined by the total 
ordering of trarsactions induced by timestamps. This is 
accomplished by piping which requires each Transaction 
Module to send its Write commands in timestamp order. One 
should note that the 'virtual' clock does not have to be 
absolutely synchronized at each site as the Transaction 
Module identifier is attached to each timestamp, rhus 
ordering the timestamps globally. 

Thus through conflict graph analysis a DBA can loosen 
the restrictions on the synchronization protocols for those 
transactions that may nor. conflict. This in turn increases 
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system performance. The technique of piping achieves 
consistency and ser ializabi lity throughout the system. 

DIS TRIEOTED QOERK PROCESSING 

In processing a query in a distributed mode one can take 
the straight forward approach and move all the transactions' 
read-sets tc a single Data Module and then execute the tran- 
saction. This however, is quite prohibitive in terms of 
communication costs for vary large read-sets and no use is 
made of parallel processing. SDD-1 attempts to solve this 
problem by splitting query processing into two distinct 
phases. The first phase reduces the read-set as much as 
possible without changing the transaction's answer. This 
reduces the amount of data to be transmitted between sites 
and makes efficient use of parallel processing as a transac- 
tion may be worked on concurrently at more than one 
Transaction Module at once. The final phase transmitts the 
reduced read-set to the final Data Module where the transac- 
tion is executed. A temporary file (buffer) is created at 
the final Data Module so that, the answer to the transaction 
can be written *o the database or displayed whichever was 
requested. 

RELIAELE WRITING 

There are three potential problems that must be solved 
tc insure that updates are reliable. The first is to guard 
against a failure of a receiving Data Module, i. e. must have 
reliable delivery. The second is to take appropriate 
measures when a failure occurs at the point of origin, i.e. 
transaction control. Finally the system must insure updates 
tc different transactions are installed in the same 'effec- 
tive' order at all Data Modules. 
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The first problem is handled by a mechanism the creators 
called spooler. It is a function/process with access to 
secondary storage devices rhat serve as first-in, first out 
(FIFO) message gusues for a failed site. Thus any message 
sent to a site which has failed will be re-routed to the 
spooler instead. Once the failed sits cooes back on-line 
updates from the spooler are processed by the failed Data 
Module. 

The second problem - transaction control - is handled in 
a more subtle way with a technique that employes a variant 
of the two-phase commit. During phase 1 the file * F’ is 
segregated into 'n' number of files corresponding to the 
receiving Data Modules. For example file *F' will be split 
into files F ( 1 ) , . . . ,F (n) to be sent to Data Modules 
DM ( 1) ,...,DM(n) . The receiving Data Modules do net install 
these files yet. This completes phase 1. During phase 2 
the Data Module that originated the transaction sends a 
commit message to each DM (1 DM (n) where upon each DM (i) 

installs F(i). If seme DM (k) has received F (k) , but not a 
commit, and the Data Module that originated the transaction 
has failed, then the DM (k) consults other DM's affected by 
the transaction. If any of the affected DM*s have received 
a commit then DM (k) proceeds to install F (k) . If no ether 
affected DM has received a commit th e transaction is 
aborted . 

Problem three, insuring updates to different transac- 
tions are installed in the same •effective 1 order at all 
Data Modules, is handled quite easily. Since every physical 
data item in the data base is timest‘amp«=d with the most 
recent updated transaction, and each update (Write command) 
carries the timestamp of the Transaction Module that gener- 
ated it; the following write rule is applied: For each data 

item, 'x’ in the update, the value of 'x' is modified at the 
Data Module if aid only if x's stored timestamp is less than 
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the timestamp of the write command. The overhead of time- 
stamps on each data item is reduced to acceptable levels by 
caching the timestamps according to the authors of SDD-1. 

SUMMARY 

SDD-1 relies heavily on the use of directories to main- 
tain the location of data throughout the system. For SDD-1 
to be effective, the management of these directories must be 
efficient and flexible. The approach taken by the authors 
is to treat the directories just like data, hence directory 
management is a design issue. Therefore, the directories 
can be fragmented, distributed with arbitrary redundancy and 
updated from arbitrary Transaction Modules. 

The development of SDD-1 uses a relational database 
management system called Data computer and runs on PDP-10 
equipment using the ARPANET and the communication network. 
The different modules require a fair amount of main memory 
for the object code, tut not an unreasonable amount. There 
does however, exist two fundamental problems with SDD-1 for 
the Coast Guard. The first, the equipment is all homoge- 
neous, hence c o nplexities are reduced somewhat. Here the 
Coast Guard cannot expect to ever be in the position of 
having homogeneous systems in the near future. Secondly, 
the Data Base Administrator (DBA) has a difficult job just 
to create a logical database design. In fact there are few 
examples of corporations that have had great success with 
this fundamental approach tc the use of database technology. 
The Data Base Administrator's job becomes ever more complex 
by having tc perform the conflict graph analysis and split- 
ting transactions into different classes. Although the 
Coast Guard has nany talented people, to find this reguired 
talent would be a herculean task. 
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